PAR  TECHNOLOGY  CORP  ROME  NY  F/6  9/2 

SABERS.  STAND-ALONE  ADIC  BINARY  EXPLOITATION  RESOURCES  SYSTEM.  — ETC(U> 
SEP  81  A  J  FRANKLIN.  R  L  CALDWELL.  S  COLE  F30602-78-C-0078 

RADC-TR-81-250-V0L-1  ML 


UNCLASSIFIED 


MICROCOPY  RESOLUTION  TEST  CHART 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  FAQt  (Whoo  D«i  Bntorod) 


'  REPORT  DOCUMENTATION  PAGE 

read  mmuenoNt 

BEFORE  COMPLETING  FORM 

1.  RE  FORT  NUMBER  11.  OOVT  ACCESSION  NO. 

RADC-TR-81-250,  Vol  I  (of  three)#/)  •'A// 

i  r^cifient'e  Catalog  number 

t 

4.  TITLE  1’aaW  SobtMe)  a 

SABERS/  ' 

STAND-ALONE  AD1C  BINARY  EXPLOITATION 

RESOURCES  SYSTEM ,  w  ,,  ? 

1,  TYRE  OF  REFORT  4  FEMOO  COVERED 

Final  Technical  Report 

April  78  -  January  81 

••  FERFORMING  ORB.  REFORT  NUMBER 

N/A 

After t  *j.  Franklin  Thomas  L.  McGlbbon  ^ 

Randy  L.  Caldwell  Kathy  H.  Michel 

Scott  Cole  James  R.  Wilson 

B.  CONTRACT  OR  GRANT  NUMBEI V«; 

F30602-78-C-0078 

S.  PERFORMING  ORGANIZATION  NAME  ANO  AOORESS 

PAR  TECHNOLOGY  CORPORATION 

228  Liberty  Plaza 

Rome  NY  13440  ' 

tA.  FROGRAM  ELEMENT.  FROJECT.  TASK 
AREA  A  WORK  UNIT  NUMBER* 

64750F 

L9550114 

II.  CONTROLLING  OFFICE  NAME  ANO  AOORESS 

Rome  Air  Development  Center  (IRDT) 

Griff iss  AFB  NY  13441 

ii.  Report  oats 

September  1981 

11.  NUMBER  OF  FADES 

L24 

MONITORING  agency  NAME  •  AOORESVK  different  from  Controlling  Ollteo) 

Same 

11.  SECURITY  CLASS,  (ol  Util,  noon) 

JNCLASSIFISD 

It*.  OECLAStl  FI  CATIOn/  DOWNGRADING 
^ ^  SCHEDULE 

16.  OlSTRIttuTlON  STATEMENT  (of  thit  Report) 

Approved  for  public  release;  distribution  unlimited 

17.  DISTRIBUTION  STATEMENT  ( ol  tkm  obmtroct  ontorod  In  Block  20.  II  dlllorcnt  from  Aoport) 

Same 

It.  SUPPLEMENTARY  NOTES 

RADC  Project  Engineer:  Garry  W.  Barringer  (IRDT) 

I*.  KEY  WORDS  (Continue  an  rararaa  tide  If  nocooomr  end  Idontttr  by  Mock  number) 

Data  Base  Management  Systems  ADCOM  Applications 

Transaction  Processing  Orbital  Mechanics 

'  Graphic  Systems 
\3perry-Univac  1652  Terminal 

20.  ABSTRACT  (Continue  an  tororoo  cldc  llnocococtr  end  Identity  by  block  number) 

The  SABERS  development  effort  has  been  to  design  and  implement  a  cohesive 
system  for  the  Aerospace  Defense  Command  (ADCOM)  to  provide  an  upgraded 
and  improved  analyst  capability  for  the  ADCOM  Intelligence  Center  (ADIC) 
and  its  missions.  In  addition,  SABERS  has  developed  system  software  (such 
as  a  data  base  management  system,  a  user  interface,  and  a  graphics  package] 
to  support  current  and  future  ADIC  application  needs. ^The  SABERS  applica¬ 
tion  system  provides  an  upgraded  capability  for  the  ADrC  analyst,  utilizes 

00  ,  '£«  1473  coition  OF  .  HOV  .» is  obsolete  UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  FACE  fWitn  Omo  Bntorod) 


UNCLASSIFIED 


If Cu Wl T V  CLAMIFICATIOW  or  THIS  PAOtfTWlaa  Oata  _ 

use,  and  is  designed  to  minimize  the  amount  of  information  the  analyst  has 
fj  enter  into  the  system.  The  application  functions  implemented  are  built 
around  a  set  of  ten  (10)  data  bases  which. are  directly  accessible  by  the 
analysts.  The  functions  include  a  number  of  numerical  and  graphical 
applications.  System  software  that  is  part  of  the  current  SABERS  imple¬ 
mentation  includes  a  data  base  management  system  (DBMS),  a  user  interface, 
and  a  graphics  package.  Goals  reached  in  the  DBMS  development  include  the 
ideal  that  the  application  programmer's  software  interface  to  the  SABERS 
DBMS  should  be  at  a  high  enough  level  such  that  the  programmer  can  easily 
describe  to  the  DBMS  the  information  content  of  his  data  base,  easily 
create  the  data  base,  and  then  easily  access  the  information  in  the  data 
base.  Furthermore,  powerful  data  base  search  and  retrieval  capabilities 
are  part  of  the  DBMS.  Data  base  management  applications  provide  a 
generalized  capability  for  examining,  updating,  adding  to  or  deleting 
information  contained  in  the  data  bases.  Goals  realized  by  the  user  inter 
face  subsystem  include  the  ideal  that  the  application  programmer's  soft¬ 
ware  interface  to  the  SABERS  user's  terminal  is  to  be  at  a  high  enough 
level  that  the  programmer  does  not  have  to  concern  himself  with  the  idio¬ 
syncrasies  of  the  terminal.  It  should  be  easy  for  the  programmer  to 
describe  to  this  interface  the  format  of  the  display  to  be  presented  to 
the  user.  It  should  be  easy  for  the  interface  to  present  the  display  to 
the  user  and  to  receive  inputs  from  him.  Finally,  it  should  be  easy  for 
the  programmer  to  access  the  inputs.  The  primary  goal  of  the  graphics 
package  which  is  realized  in  SABERS  is  the  ideal  that  an  application 
programmer  should  be  able  to  describe  a  picture  to  the  graphics  package 
using  data  values  he  understands.  The  graphics  package  performs  all  the 
necessary  transformations  to  map  a  picture  from  the  user's  coordinate 
system  into  the  terminal's  coordinate  system.  The  graphics  package  is 
also  as  terminal-independent  as  possible.  A  major  part  of  the  SABERS 
effort  was  the  development  of  software  for  the  Sperry-Univac  1652  terminal 
This  development  involved  designing  and  implementing  code  within  the  1652 
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1.  INTRODUCTION 


This  report  contains  the  final  svanary  of  the  work  accomplished  under 
Contract  F30602-78-C-0078 ,  entitled  the  "Stand-Alone  ADIC  Binary  Resource 
System",  referred  to  as  SABERS.  This  report  is  in  compliance  with  Data  Item 
007  of  contract  Line  Item  0002  of  this  contract. 

The  total  doc  mentation  of  the  accomplishments  realized  in  the 
performance  of  the  SABERS  contract  is  being  provided  in  two  separate 
documents : 

o  This  final  report,  which  provides: 

1.  The  description  of  the  design  objectives  of  the  software  and  of 
the  miner ical  algorithms  (the  body  of  the  report). 

2.  The  information  required  by  the  users  to  employ  the  functional 
tools  and  to  maintain  the  software  (the  User  Manuals  contained 
in  Appendices  A-F) . 

o  The  computer  program  documentation,  which  describes: 

1.  The  particulars  of  the  routines  and  subroutines. 

2.  The  schema  of  each  of  the  data  bases. 

1 . 1  BACKGROUND 

The  purpose  of  the  SABERS  effort  was  to  develop  a  set  of  tools  to 
demonstrate  improvements  to  the  Aerospace  Defense  Command  (ADC0M)  intelligence 
analyst  at  the  ADC0M  Intelligence  Center  (ADIC).  SABERS  requirements  included 
the  ability  to  review  past  and  current  events  using  a  computerized  data  base. 
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mathematical  analysis  of  space  phenomena,  graphical  presentation  of  the 
results  of  the  analysis,  and  uniform  and  efficient  user  interaction. 
Additional  constraints  were  portability,  terminal  independence,  structured 
programming,  and  docunentation . 

SABERS  uses  existing  software,  where  possible.  In  addition,  the  newly 
developed  software  is  portable  within  the  I&W  community  (AN/GYQ-21 (V) 
environment).  The  software  was  developed  on  the  Digital  Equipment  Corporation 
(DEC)  VAX  11/780  computer  in  compatibility  mode.  Compatibility  mode  emulates 
the  DEC  PDF  11/70  minicomputer  and  the  RSX-11M  operating  system. 

Terminal  independence  is  accomplished  in  SABERS  through  the  existence  of 
interface  utilities  which  translate  between  software  and  hardware  protocol. 
This  mechanism  allows  uniform  software  coding  for  input  and  output  at  the 
application  level,  and  defers  terminal  considerations  to  the  interface 
software. 

SABERS  software  is  designed  to  be  modular.  Although  the  programming 
languages  are  FORTRAN  and  assembler,  the  code  produced  is  as  structured  as 
possible.  Docunentation  is  provided  at  the  program  level  in  the  program 
listings,  at  the  system  level  in  the  computer  program  docunentation  and  at  the 
user  level  in  this  report. 

1.2  POTENTIAL  USERS  OF  SABERS 

SABERS  docunentation  addresses  three  classes  of  users,  the  Space  and 
Missile  Analyst  (SMA),  the  application  programmer ,  and  the  program  maintainer. 
The  SMA  is  the  ADIC  analyst  using  the  end  product  to  research  past  events  and 
to  analyze  present  situations.  The  application  programmer  is  the  designer  and 
coder  of  new  applications  to  be  included  in  SABERS.  The  program  maintainer  is 
the  systems  programmer  modifying  and  updating  the  existing  SABERS  code. 


The  knowledge  requirements  of  each  user  are  distinct.  The  SMA  must  know 
how  to  cause  SABERS  to  execute  its  applications,  and  how  to  interact  with  the 
application  routines.  The  application  programmer  must  know  what  the  existing 
software  accomplishes,  and  how  to  call  the  subroutines  and  functions  he  needs. 
The  program  maintainer  must  know  how  the  routines  perform  their  functions  and 
how  modification  will  affect  the  other  software. 

1.3  SUMMARY  OF  THE  FUNCTIONAL  AREAS 

The  result  of  the  SABERS  contract  is  a  complementary  structure  of 
routines  in  six  functional  areas:  applications,  map  drawing,  user 

interaction,  graphics,  data  base  management,  and  terminal  control.  The 
software  developed  in  each  of  these  areas  is  designed  to  interact  with  and 
support  all  of  the  other  areas.  This  complementary  structure  provides  a 
testbed  for  the  SMA  to  evaluate  the  effectiveness  of  computer  aided  research 
and  analysis.  In  providing  this  service,  the  complementary  structure 
functions  as  a  preliminary  system  design;  therefore,  it  is  referred  to  as  the 
SABERS  system  throughout  the  documentation. 

Each  of  the  six  functional  areas  of  the  SABERS  system  is  designed  to 
provide  capabilities  which  may  be  easily  modified  and  expanded.  With  the 
exception  of  the  applications  and  map  drawing  functional  areas,  the  collection 
of  software  composing  a  functional  area  may  be  extracted  as  a  unit  from  the 
complementary  structure  and  integrated  within  some  different  software 
structure.  The  software  composing  each  functional  area  provides  a  basis  for 
the  corresponding  unit  which  is  to  be  implemented  in  an  operational  SMA 
system . 


1.3. t  Applications 

SABERS  applications  software  is  composed  of  routines  that  are  developed 
to  solve  problems  of  interest  to  the  SMA.  The  problems  are  related  to  data 
organized  in  the  following  areas: 
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•  summary  information  about  all  current  and  historical  launch  events 


•  description  of  characteristics  and  capabilities  of  all  launch  vehicles 

•  description  of  characteristics  and  capabilities  of  all  launch  pads 

•  description  of  characteristics  and  capabilities  of  Blue  tracking  radar 
systems 

•  description  of  characteristics  and  capabilities  of  Blue  spaceborne 
systems 

•  description  of  the  status  of  all  objects  in  space 

•  description  of  characteristics  and  capabilities  of  Red  support  facilities 

•  collection  of  orbital  element  sets  collected  by  Blue  radar  sensors 

•  collection  of  IR  values  collected  by  Blue  IR  sensors 

•  collection  of  polynomial  coefficients  reported  by  Blue  IR  sensors 

The  problems  include  reviewing  and  updating  the  data,  performing  analysis 
on  the  data  to  compute  the  parameters  of  space  phenomena  (such  as  the  time  and 
location  of  a  space  launch) ,  and  presenting  the  data  and  analytic  results  in  a 
graphic  format  (such  as  the  location  of  Red  support  facilities  and  the  ground 
trace  of  an  orbiting  payload). 

The  application  routines  act  as  executive  routines.  These  routines  make 
calls  to  the  routines  in  the  remaining  functional  areas  to  draw  maps,  request 
data  from  the  SABERS  data  bases,  interact  with  the  SMA,  and  plot  graphical 
outputs. 
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1.3.2  Map  Drawing 

The  map  drawing  routines  provide  the  computation  necessary  to  draw  the 
different  map  projections  required  as  background  for  some  application  plots. 
The  routines  rely  upon  the  data  base  routines  to  access  the  map  data  and  upon 
the  graphics  routines  to  plot  the  maps. 

1.3.3  User  Interaction 


The  SMA  interacts  with  the  applications  through  the  Terminal  Independent 
Transaction  Processor  (TITP) .  TITP  presents  a  form  to  the  analyst  with  the 
names  of  the  data  required  and  possible  default  values.  U3ing  the  screen 
editing  capabilities  of  TITP,  the  SMA  enters  the  desired  values  and  sends  the 
data  to  the  application.  TITP  performs  error  checking  before  sending  the 
information  back  to  the  application. 

The  user  interaction  routines  allow  the  application  programmer  to 
describe  the  format  of  an  entire  screen  image;  that  is,  to  describe  the 
location  of  the  fields  within  the  screen,  the  data  types  of  each  field  and  the 
legal  values  of  each  field.  TITP  also  allows  the  application  to  address, 
modify,  and  read  the  fields  of  a  screen  image  by  name. 

1.3.4  Graphics 

Applications  cause  graphic  output  to  be  produced  by  calling  routines  in 
the  Terminal  Independent  Graphics  Processor  (TIGP).  TIGP  is  a  direct 
implementation  of  the  ACM-SIGGRAPH  Core  proposed  graphic  system  standard. 

1.3.5  Data  Base  Management 

Applications  manipulate  the  data  through  the  SABERS  Data  Base  Management 
System  (DBMS).  The  data  is  organized  into  data  bases  managed  by  the  DBMS. 
These  data  bases  are  easily  defined  and  created  by  the  application  programmer 
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using  the  provided  data  description  language.  DBMS  provides  capabilities  to 
add,  update,  and  delete  information  within  the  data  bases.  DBMS  supports 
complex  assertions  on  multiple  key  fields  in  performing  data  base  searches. 

The  SABERS  DBMS  is  developed  using  DEC  RMS-11,  capable  of  searching  an 
indexed  sequential  file  based  on  a  single  key.  The  SABERS  implementation 
includes  a  FORTRAN  interface  to  RMS-11,  complex  multi-key  queries,  multiple 
indexed  sequential  files  and  multi-user  operations. 

1.3.6  Terminal  Control 


The  terminal  identified  as  the  primary  analyst  terminal  is  the  Sperry- 
Univac  1652  (S-U  1652)  terminal.  The  first  known  interface  between  the  S-U 
1652  and  the  VAX  was  developed  for  SABERS  using  the  DZ11-A  asynchronous 
multiplexer  for  EIA  RS-232  terminals,  making  the  S-U  1652  look  like  any 
teletype  device  to  the  VAX,  and  allowing  the  use  of  the  DEC  supplied  device 
driver  for  communication. 

In  addition  to  supporting  the  communication  protocol ,  the  developed 
software  supports  the  programming  of  the  variable  function  "soft  keys."  The 
soft  key  i3  programmed  with  a  sequence  of  characters,  which  are  transmitted  to 
the  VAX  for  interpretation  whenever  the  analyst  presses  the  soft  key. 
Software  is  also  provided  to  download  predefined  soft  key  definitions  from  the 
VAX. 


1 .4  SUMMARY  OF  THE  DOCUMENT 

The  organization  of  this  report  is  based  upon  the  organization  of  SABERS. 
The  documentation  of  each  functional  area  is  provided  in  an  appendix  which  may 
be  extracted  from  the  report  at  the  same  time  the  software  unit  is  extracted 
from  the  SABERS  system.  The  information  appropriate  for  each  type  of  user  is 
provided  in  the  appendix  for  the  functional  area. 
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The  remainder  of  this  report  is  divided  into  2  sections,  6  appendices. 


and  one  attachment: 

e  Section  2  describes  the  software  architecture.  It  describes  the 
interaction  required  by  the  functional  areas  in  the  complementary 
structure . 

e  Section  3  describes  the  mathematical  algorithms  used  in  the  SABERS 
applications. 

•  Appendix  A  is  the  Space  and  Missile  Analyst  User  Manual,  describing  the 
operation  of  the  SABERS  system  and  the  user's  interaction  with  the 
applications  in  the  application  functional  area. 

•  Appendix  B  is  the  Applications  Programmer  User  Manual  and  Program 

Maintenance  Reference  Manual  for  the  SABERS  map  drawing  functional  area. 

•  Appendix  C  is  the  Applications  Programmer  User  Manual  and  Program 

Maintenance  Reference  Manual  for  the  Terminal  Independent  Transaction 
Processor  (TITP) ,  the  SABERS  user  interaction  functional  area. 

•  Appendix  D  is  the  Applications  Programmer  User  Manual  and  Program 

Maintenance  Reference  Manual  for  the  Terminal  Independent  Graphics 
Processor  (TIGP),  the  SABERS  graphics  functional  area. 

•  Appendix  E  is  the  Applications  Programmer  User  Manual  and  Program 

Maintenance  Reference  Manual  for  the  Data  Base  Management  System  (DBMS) , 
the  SABERS  data  base  management  functional  area. 

•  Appendix  F  is  the  Program  Maintenance  Reference  Manual  for  the  Sperry- 
Univac  1652  terminal,  the  SABERS  terminal  control  functional  area. 


1-7 


a  copy  of  the  FLECS  User  Manual.  This  is  provided  for 
rammers  and  program  maintainers  who  may  wish  to  write  new 
FLECS,  or  who  may  need  to  read  the  source  code  of  SABERS. 
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2.  SABERS  SOFTWARE  ARCHITECTURE 


This  section  describes  the  method  of  interaction  between  the  functional 
units  composing  the  SABERS  system.  Section  2.1  presents  the  system  overview. 
Section  2.2  discusses  the  interprocess  communication  mechanism,  and  Section 
2.3  discusses  the  use  of  data  bases  and  data  files. 

2.1  SABERS  SYSTEM  OVERVIEW 

The  process  image  size  under  the  RSX-11M  operating  system  is  32k  words. 
Since  the  total  storage  requirements  of  all  the  SABERS  software  is  much 
greater  than  this  limit,  the  software  is  modularized  into  several  independent 
utility  processes  which  operate  concurrently  with  the  application  processes  in 
support  of  the  applications.  These  utility  processes  communicate  with  the 
application  processes  through  the  use  of  the  Macro-11  Assembler  interface 
described  in  Section  2.2. 

Two  of  these  utility  processes  coordinate  the  multi-user  access  to  the 
SABERS  data  bases.  These  utilities  are  the  Data  Base  Manager  (DBM)  and  the 
Memory  Management  Service  (MMS) .  The  DBM  processes  the  data  base  access 
requests,  and  the  MMS  manages  the  tables  necessary  for  DBM  to  work.  These  two 
utilities  are  invoked  once  to  support  all  SABERS  users,  and  their  resources 
are  shared  among  all  applications.  These  utilities  together  form  the  Data 
Base  Management  System  (DBMS) . 

The  remaining  two  utilities  are  the  Terminal  Independent  Transaction 
Processor  (TITP)  and  the  Terminal  Independent  Graphics  Processor  (TIGP).  A 
unique  local  copy  of  each  utility  is  invoked  for  each  user.  The  local  copy 
includes  the  Device  Manager  (DM)  appropriate  for  the  user’s  terminal.  The  DM 
is  a  Macro-11  Assembler  interface  for  the  type  of  terminal  on  which  the  user 
is  logged  in. 
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The  SABERS  account  is  maintained  on  the  computer  in  the  fora  of  a 

directory  tree.  The  root  of  the  tree  is  the  SABERS  default  directory.  This 
is  the  directory  in  which  the  DBM  and  MMS  utilities  are  initiated.  A 

subdirectory  (or  branch)  off  the  SABERS  root  is  maintained  for  each  recognized 
SABERS  user.  The  user  initiates  the  execution  of  applications  routines  from 
his  subdirectory.  The  local  copies  of  the  user's  TITP  and  TIGP  utilities  are 
also  initiated  in  this  subdirectory. 

The  user's  SABERS  environment  is  established  at  the  time  the  user 

"logs-on"  to  the  system  (the  log-on  procedure  is  described  in  Appendix  A,  the 
Space  and  Missiles  Analyst  User  Manual).  If  DBM  and  MMS  are  not  currently 
running,  they  are  initiated  in  the  SABERS  root  directory  as  detached 
(ownerless)  shareable  processes.  After  the  user  is  verified  to  SABERS  through 
the  use  of  a  system  password,  the  correct  default  user  subdirectory  is 
established.  The  versions  of  TITP  and  TIGP  with  the  DM  for  the  user’s 

terminal  type  are  copied  from  the  SABERS  root  directory  to  the  user's  default 
subdirectory  and  invoked.  SABERS  applications  may  then  be  initiated  by  the 
user.  The  requested  application  is  copied  from  the  SABERS  root  directory  to 
the  user's  default  subdirectory  and  initiated.  This  guarantees  that  the 
application  process  is  local  and  unique  to  the  user. 

An  application  process  expires  as  soon  as  its  task  is  completed.  The 
local  copy  of  the  application  is  deleted  from  the  user's  default  subdirectory 
to  prevent  the  buildup  of  files  in  the  user's  area.  The  local  copies  of  the 
TITP  and  TIGP  processes  expire  and  are  deleted  when  the  user  logs  off  from  the 
system.  The  DBMS  utilities  (DSM  and  MMS)  are  ownerless,  and  are  halted  by 
SABERS  when  the  number  of  SABERS  users  reaches  zero.  Thus  the  first  SABERS 
user  may  log  off  without  affecting  any  other  user. 

The  system  environment  for  three  users  is  pictured  in  Figure  2-1.  In 
this  figure. 
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USER  X 


USER  2 


USER  3 


Figure  2-1  The  Current  SABERS  System  Organization 
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o  solid  rectangles  are  independent  processes 

o  processes  enclosed  in  dashed  boxes  are  operating  under  the  user's 
default  subdirectory 

o  DBM  and  MMS  are  operating  under  the  SABERS  root  directory 

o  DM  is  a  terminal  specific  module  required  to  interface  the  utility  to 
the  user's  terminal 

o  arrows  show  the  lines  of  communication. 

2.2  THE  INTERPROCESS  COMMUNICATION  MECHANISM 

The  utility  processes  communicate  with  an  application  process  through  a 
Macro-11  Assembler  interface.  This  interface  makes  use  of  the  system  service 
message  sending  capabilities  and  the  global  event  flag  capabilities  of  the 
RSX-11M  operating  system. 

The  interface  modules  are  part  of  the  application  processes,  and  are 
constructed  to  make  the  communication  mechanism  transparent  to  the  application 
programmer.  The  application  program  includes  calls  to  the  utilities  just  as- 
if  the  utilities  were  physically  part  of  the  application  process.  The 
interface  intercepts  these  subroutines  calls  and  transforms  them  into  messages 
directed  to  the  appropriate  utility  process.  The  interface  copies  the 
parameters  of  the  subroutine  call  into  a  message  buffer  and  sends  the  message 
buffer  in  13-word  packets  to  the  utility  process,  using  the  Send  Data  System 
Service.  After  the  message  is  sent,  the  application  process  "hibernates" 
(takes  up  no  system  resources). 

The  operating  system  delivers  the  message  to  the  utility  by  generating  an 
Asynchronous  System  Trap  which  awakens  the  hibernating  utility.  (Note  that 
placing  inactive  processes  in  a  state  of  hibernation  allows  the  operating 
system  to  manage  the  active  executing  processes  more  efficiently) .  The 
incoming  message  is  decoded  by  the  interface  into  a  standard  FORTRAN  call 
which  is  then  executed.  Thus,  the  communication  interface  is  also  transparent 
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to  the  utility  programmer.  When  the  utility  is  finished  executing,  the 
results  are  made  available  to  the  calling  application  through  the  transmission 
of  a  message  through  the  operating  system. 

One  further  refinement  is  required  in  interfacing  with  the  DBM  because  ef 
its  global  nature.  Since  requests  for  data  base  operations  may  be  made  by 
several  applications,  a  synchronization  mechanism  to  insure  security  of  access 
is  provided  by  the  global  event  flag  capability  of  the  operating  system.  The 
application  interface  waits  until  the  global  flag  shows  that  the  DBM  is 
available,  sets  it  to  show  the  DBM  is  not  available,  and  sends  the  message. 
The  application  interface  resets  the  global  flag  after  receiving  the  data 
transfer  from  the  DBM. 

2.3  DATA  BASES  AMD  DATA  FILES 

Information  necessary  for  the  operation  of  SABERS  is  stored  in  data  bases 
and  data  files.  Global  information  available  to  all  users  is  stored  in  the 
SABERS  root  directory.  Global  data  bases  contain  the  map  data  (coastlines  and 
political  boundaries)  and  the  data  organized  to  support  the  applications 
developed  to  solve  problems  of  interest  to  the  SMA  (as  presented  in  Section 
1.3).  Any  changes  to  these  global  data  bases  affects  all  other  SABERS  users. 

Local  information,  which  is  not  accessible  to  any  other  SABERS  users,  is 
maintained  in  the  individual  user's  default  subdirectory.  In  addition  to  any 
local  data  base  required  by  applications,  local  data  bases  exist  to  store  the 
map  plotting  parameters,  the  current  launch  event  identification  nuaber,  and 
the  last  record  reviewed.  Local  data  files  are  used  by  the  local  copy  of  TIGP 
to  store  retained  segments,  and  by  the  local  copy  of  TITP  to  store  screen 
display  formats  and  screen  responses. 

Data  bases  and  data  files  established  and  maintained  by  the  utilities  are 
transparent  to  the  user  and  the  application  programmer.  The  information 
stored  is  used  to  perform  calculations,  to  provide  default  responses,  to  aid 
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graphics,  to  format  and  display  transaction  screens,  and  to  check  user 
responses. 

2.4  STRUCTURED  PROGRAMING 

To  support  structured  programming  in  a  FORTRAN  environment,  the  FORTRAN 
Language  Extended  Control  Systems  (FLECS)  preprocessor  has  been  employed  where 
feasible.  Such  SABERS  facilities  as  TIGP,  TITP,  the  map  drawing  routines,  the 
Data  Base  Management  System,  and  some  applications,  have  been  programmed  using 
FLECS.  A  copy  of  the  FLECS  User's  Manual  is  included  with  this  report. 

FLECS  expands  the  FORTRAN  language  by  making  the  control  structures 
recommended  by  modern  programmi^  practices  available  to  the  FORTRAN 
programmer.  These  structures  include  IF,  UNLESS,  WHEN  .  .  .  ELSE, 
CONDITIONAL,  SELECT,  DO,  WHILE,  WHILE,  UNTIL,  and  REPEAT  UNTIL.  In 

addition,  editorial  features,  such  as  Indenting,  are  provided  to  improve  the 
appearance  and  readability  of  printed  programs. 

The  FLECS  preprocessor  accepts  programs  which  use  these  conventions  and 
outputs  code  which  conforms  to  FORTRAN  66  standards  for  compilation  in  a 
production  compiler.  FLECS  was  made  available  without  charge  to  this  contract 
and  is  available  without  charge  to  SABERS  as  implemented  on  the  AN/GYQ-2KV) . 
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3.  SABERS  APPLICATION  ALGORITHMS 


This  section  describes  the  mathematical  algorithms  developed  for  SABERS. 
The  time  algorithms  presented  in  Section  3. 1  and  the  coordinate  systems 
discussed  in  Section  3*2  are  used  in  almost  all  of  the  SABERS  applications. 
Although  the  calculation  of  a  satellite  ground  trace  is  important  in  many  of 
the  applications,  the  algorithms  presented  in  Section  3.3  are  directly  used  in 
the  OVERLAY  GROUND  TRACE  and  OVERLAY  TIME  MARKS  ON  GROUND  TRACE  applications. 
The  solution  of  the  radar  related  problem  discussed  in  Section  3.4  are  the 
basis  for  the  RADARS  VS.  ORBIT  applications.  The  algorithms  developed  in 
Section  3.5  for  the  photo  reconnaissance  problems  are  used  in  the  SATELLITE 
RECONNAISSANCE  applications.  The  equations  presented  in  Section  3.6  describe 
the  algorithm  used  in  the  GENERATE  THREAT  WINDOWS  application.  The  equations 
used  to  generate  and  plot  points  on  the  different  map  backgrounds  for  the 
application  outputs  are  presented  in  Section  3.7. 

3.1  TIME  ALGORITHMS 

Time  is  represented  in  SABERS  by  two  values,  the  calendar  day  and  the 
clock  time  since  midnight.  The  user  enters  and  receives  the  calendar  day  as 
the  Gregorian  date  (year,  month  and  day),  or,  alternatively,  as  (year,  day 
number),  in  which  the  month  and  day  information  have  been  combined  into  the 
day  number.  The  clock  time  is  presented  and  received  by  the  user  as  mean 
solar  time  (hour,  minute,  second)  in  24-hour  format. 

The  algorithms  expect  the  calendar  day  to  be  encoded  as  a  Julian  date 
relative  to  January  0,  1900  at  midnight,  and  the  clock  time  to  be  the 
fractional  part  of  the  day  since  midnight.  The  benefits  derived  are  simple 
time  difference  calculations,  and  the  ability  to  express  the  exact  time  in  one 
value  (the  complete  Julian  day  *  Julian  date  +  fractional  day). 
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3.1.1  Julian  to  Gregorian  Date  Conversion 

The  conversion  between  the  user  representations  of  time  and  the  algorithm 
representations  of  time  are  based  upon  two  algorithms  presented  by  Henry  F. 
Fliegel  and  Thomas  C.  Van  Flandern  in  the  Letters  to  the  Editor  section,  page 
657,  of  reference  [4].  The  algorithms  were  presented  as  a  FORTRAN  arithmetic 
statement  function  and  as  a  FORTRAN  subroutine. 


3. 1.1.1  Gregorian  to  Julian  Date  Conversion 


The  Julian  date  arithmetic  statement  function  as  presented  by  the  authors 
returns  an  integer  Julian  date  at  noon  valid  for  any  Gregorian  date  producing 
a  Julian  date  greater  than  zero.  The  algorithm  makes  use  of  the  truncation 
feature  of  integer  arithmetic  in  FORTRAN. 

JD  (I,  J,  K)  =  K  -  32075  +  1461  »  (I  +  4800  +  (J  -  14)  /  12)  /  4 

+  367  «  (J  -  2  -  (J  -  14)  /  12  «  12)  /  12 

-  3  *  ((I  +  4900  +  (J  -  14)  /  12  /  100)  /  4 

where  I  =  year,  J  =  month  (number  from  1  to  12)  and  K  =  day  of  month. 

This  algorithm,  when  evaluated  for  December  31,  1899,  yields  JD  = 

2415020.  This  implies  that  the  Julian  date  of  January  0,  1900  at  midnight  is 
2415020.5.  Changing  the  function  to  a  real-valued  function,  and  recognizing 
that  the  time  interval  between  two  Julian  dates  is  the  difference  of  the  two 
Julian  dates,  the  SABERS  algorithm  to  convert  from  (year,  month,  day)  to 
Julian  date  is: 


DAY  (IYEAR,  MONTH,  IDAY)  =  IDAY  -  32075 

+  1461  «  (IYEAR  +  4800  +  (MONTH  -  14)  /  12)  /  4 

+  367  *  (MONTH  -  2  -  (MONTH  -14)  /  12  •  12)  /  12  (3-1) 

-  3  *  ((IYEAR  +  4900  +  (MONTH  -  14)  /  12  /  100)  /  4 

-  2515020.5 
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3. 1.1. 2  Julian  to  Gregorian  Day  Number  Conversion 


A  closed  form  expression  may  be  derived  from  the  FORTRAN  expression  (3-D 
to  convert  from  (year,  day  number)  to  Julian  date.  Letting  JUL  be  the  real¬ 
valued  Julian  date  required,  and  DNUM  be  the  day  number,  we  want 

JUL  a  DNUM  +  DAY  (IYEAR  -  1,  12,  3D 


Substituting  IYEAR  =  IYEAR  -  1,  MONTH  a  12  and  IDAY  =  31  in  (3-D,  we  find 


JUL  =  DNUM  +  365  •  IYEAR  +  (IYEAR  -  1)  /  4 

-  3  *  ((IYEAR  -  1)  /  100  +  1)  /  4 

-  693960.5 


again  making  use  of  the  integer  truncation  feature  of  FORTRAN. 


3. 1.1.3  Julian  to  Gregorian  Date  Conversion 


The  second  algorithm  presented  by  the  authors  converts  from  the  Julian 
date  JD  to  the  year,  month,  and  day.  Written  in  the  form  of  a  FORTRAN 
subroutine,  it  also  makes  use  of  the  integer  truncation  feature  of  FORTRAN. 


SUBROUTINE  DATE  (JD,  IYEAR,  MONTH,  IDAY) 

L  a  JD  ♦  68569 

N  a  4  *  L  /  146097 

L  =  L  -  (146097  »  N  +  3)  /  4 

I  =  4000  •  (L  +  1)  /  1461001 

L  =  L  -  1461  *1/4+31 

J  =  80  *  L  /  2447 

IDAY  =  L  -  2447  •  J  /  80 

L  a  J  /  11 

MONTH  aJ+2-12«L 

IYEAR  a  100  *  (N  -  49)  +  I  ♦  L 

RETURN 

END 
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The  SABERS  subroutine  differs  only  in  replacing  the  Input  integer  Julian 
date  JD  with  a  real  Julian  Date  D  and  adding  the  Julian  date  of  January  0, 
1900  at  midnight.  The  first  line  of  the  subroutine  is  thus  replaced  by 

SUBROUTINE  DATE  (D,  IYEAR,  MONTH,  IDAY) 

JD  =  D  +  2415020.5 

Of  course,  the  Gregorian  date  may  be  expressed  as  (year,  day  number)  by 
solving  for  the  day  number  DNUM  with  (2  -  1)  by 

DNUM  =  DAY  (IYEAR,  MONTH,  DAY)  -  DAY  (IYEAR  -  1,  12,  3D 

3.1.2  Mean  Solar  Time-Fractional  Day  Conversion 

The  conversion  between  mean  solar  time  and  fractional  day  since  midnight 
is  straightforward.  Let  F  =  fractional  day,  H  =  hour  (24-hour  clock),  M  = 
minute  and  S  =  second,  then 

F  =  (H  *  3600  +  M  «  60  +  S)  /  86 400 


7 

and 


H  =  (24  »  F] 

M  =  [1440  *  F  -  60  •  H] 

S  =  86400  *  F  -  60  «  H  -  3600  *  M 


where  [X]  means  the  greatest  integer  function  of  X. 


3.2  COORDINATE  SYSTEMS 


There  are  three  coordinate  systems  used  to  describe  a  point's  location. 
These  are  the  earth-centered  inertial  (ECI),  the  geocentric,  and  the  local 
topographic  (ENU)  coordinate  system.  An  orbital  element  set  is  used  to  define 
a  satellite's  position,  and  will  also  be  described  in  this  section. 
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3.2.1  Earth-Centered  Inertial  Coordinate  System 


The  earth-centered  inertial  (ECI)  coordinate  system  has  its  origin  at  the 
center  of  the  earth.  The  principal  axis  points  toward  the  vernal  equinox 
(denoted  by  y  ).  The  x-y  plane  is  in  the  earth's  equatorial  plane,  and  the  z 
axis  points  to  the  north  pole 4  completing  the  right  hand  system  (See  Figure 
3-D. 


The  ECI  coordinate  system  is  the  reference  system  for  the  other  systems 
in  this  section.  This  is  a  result  of  the  characteristic  of  the  ECI  coordinate 
system  that  it  does  not  change  in  its  orientation  in  the  time  scales  the 
SABERS  algorithms  deal  with. 

3.2.2  Geocentric  Coordinate  System 

The  geocentric  coordinate  system  is  a  rotating  frame  of  reference.  The 
origin  of  the  system  is  the  center  of  the  earth.  The  coordinates  of  a  point 
are  given  as  (  <P  ,  h),  where  *  is  the  longitude,  is  the  geodetic 
latitude,  and  h  is  the  altitude  of  the  point  above  the  reference  ellipsoid. 
As  shown  in  Figure  3-1,  the  longitude  is  the  angular  deviation,  measured  at 
the  equator,  of  the  meridian  passing  through  the  point  from  the  Prime  Meridian 
(passing  through  Greenwich,  England),  -180°^  A  <  180°.  By  convention,  a 
positive  longitude  indicates  that  the  point  is  to  the  east  of  Greenwich. 

The  earth  is  modeled  as  an  ellipsoid  generated  by  rotating  an  ellipse 
about  the  z  axis.  As  shown  in  Figure  3-2,  the  line  from  a  point  P 
perpendicular  to  the  reference  ellipsoid  at  A  will  intersect  the  equatorial 
plane  at  B.  The  acute  angle  of  intersection  at  B  is  defined  as  the  geodetic 
latitude  <4> .  The  geocentric  latitude  $  is  defined  as  the  angle  between  A 
and  the  equatorial  plane  measured  at  the  center  of  the  earth.  These  angles 
are  related  by 
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Ellipsoid  Earth  Model 


tan  4  =  -tan'  4  ,  0°  <  4>  <  90°  ,  0°  <  ♦'  <  90° 

(i  -  r)  “  "  “ 


f  = 


The  distance  along  the  perpendicular  between  P  and  A  is  defined  as  the 
altitude  above  the  reference  ellipsoid  h. 


3.2.2. 1  Hour  Angle 

The  geocentric  coordinate  system  described  above  is  a  rotating  system. 
The  angular  deviation  of  any  point  from  the  vernal  equinox  at  time  t  is 
defined  as  the  hour  angle  0  .  As  shown  in  Figure  3-1,  0  =  eG  +  X  ,  where  0q  is 
the  hour  angle  of  the  Prime  Meridian.  As  reported  in  reference  [33,  pages 
20-21 ,  the  Greenwich  hour  angle  may  be  closely  approximated  by 


0 


G 


At 


d0 

dt 


where 


er  =  99.6909833°  ♦  36000.7689°  T„  +  0.00038708  T* 

u  u  u 

o 


with 


Julian  date  at  midnight  relative  to  January  0,  1900 

36525 


At  =  fractional  days  since  midnight 
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revolutions/year 


dt  s  365. 242 19879 

=  360.9856473  degrees/day 

The  hour  angle  0,  0°  <  0  <  360°,  defines  the  linkage  between  the  rotating 
geocentric  and  non-rotating  ECI  coordinate  systems. 

3.2. 2. 2  Geocentric  to  ECI  Transformation 

The  transformation  from  geocentric  coordinates  to  ECI  coordinates  is 
taken  directly  from  Transformation  4,  pages  399-400,  in  reference  [31  (See 
Figure  3-2). 


X.  <p.  h,  e  G  ->  x,  y,  z 
ij)’  =  tan-1  [(1  -  f)2  tan  <|>  ] 

2  a*  [  1  -  <2f  -  f2)  ] 

'  1  -  (2f  -  f2)  CO,2  ♦’ 

R  s-^R2  +  h2  +  2Rq  h  cos  <  <f>  -  $  ) 

6  *  ♦  sin-1  [  |  sin  <♦-♦')  ] 

6  «  6g  ♦  X 

x  =  R  cos  S  cos  0 


y  =  R  cos  6  sin  6 
z  =  R  sin  6 


W''" 


a@  s  semi-major  axis  of  the  earth 
=  1  e.r.  (earth  radius) 

=  6378.16  km. 


3.2.2. 3  ECI  to  Geocentric  Transformation 

The  transformation  from  ECI  to  geocentric  coordinates  is  taken  directly 
from  Transformation  3,  pages  398-399.  in  reference  1 33  (See  Figure  3-2). 


x,  y.  z,  ® q  ->  X  ,  $  ,  h 

R  =\fx2  ♦  y2  +  z2 
a  =  tan-1  (  ) 

X  =  a  -  0G  .  -180°  <  X  <  180° 

6  -  tan"1  -  z- -  ,  -90°  <  &  <  90° 

V-2  * y2 

f 

Starting  with  the  estimate  <t>  =  the  following  equations  are  executed  in  an 

t 

iterative  manner  until  <t>  is  within  the  required  tolerance. 


R 

c 


i  -  (2f  -  r) 


1  -  (2f  -  f2)  cos2 


4> 


tan 
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w 


h  *  V  R ~  C  sin  <  ♦  ”  ♦  )  -  *c  eo»  (  ♦  -  ♦  ) 


<(,'  *  <5  -  sin-1  £  sin  ( 4  -  $')J 


3.2.3  Local  Topocentrlc  Coordinate  System 

The  local  topocentrlc  coordinate  system  used  by  the  SABERS  algorithms  is 
defined  by  pointing  the  principal  e-axis  towards  local  east,  pointing  the  n- 
axis  towards  local  north,  and  completing  the  right  hand  system  by  pointing  the 
u-axis  up  (See  Figure  3-3). 

The  transformation  from  ECI  coordinates  to  local  topocentrlc  coordinates 
is  given  as  follows: 


where! y I  is  the  origin  of  the  local  topocentrlc  system  in 

\zl  o 

and  G  is  the  rotation  matrix  (see  page  319  in  reference  [5] 
reference  [8]  ), 


ECI  coordinates 
and  page  3-5  in 


G 


-sin  0 

I 

-sin  $  cos  6 

i 

cos  4  COS  0 


cos  e 

-sin  sin  0 

t 

cos  $  sin  0 


0 

I 

cos  4 
sin  <f> 


where  $  is  the  geocentric  latitude  of  the  origin  and  e  is  the  hour  angle  of 


th®  origin.  At  time  t,  the  location  of  the  origin  expressed  in  ECI 
coordinates  determines  the  hour  angle  and  the  coordinates  of  the  origin  in  the 
geocentric  coordinate  system  via  the  algorithms  presented  in  Sections  3.2.2. 1, 
3. 2. 2. 2,  and  3. 2. 2. 3. 

3.2.4  Orbital  Element  Set 


The  development  presented  in  this  section  is  due  to  Dr.  Ranjan  V. 
Sonalkar,  as  reported  in  reference  [8],  pages  3-1  to  3-21. 

3.2.4. 1  Description  of  the  Orbital  Elements 

SABERS  algorithms  receive  satellite  orbit  information  in  the  set 

•  •  • 

(  Tg,  0,  e,  i,  (a,  M,  n,  The  epoch  time,  Tg,  is  the  time  for  which 

the  orbital  element  set  has  been  observed.  As  shown  in  Figure  3-4,  the  right 

ascension  of  the  ascending  node,  0,  is  an  angle  measured  in  the  earth's 

equatorial  plane.  It  is  defined  by  the  vernal  equinox  and  the  ascending  node 

(the  intersection  of  the  orbit  plane  and  the  equatorial  plane  for  which  the 

satellite  is  ascending  from  the  southern  hemisphere  to  the  northern 

hemisphere).  The  eccentricity  of  the  orbit,  e,  is  assumed  to  be  0  <  e  <  1, 

defining  an  elliptic  orbit  with  the  center  of  the  earth  at  one  focus.  The 

inclination,  i,  is  the  angle  between  the  equatorial  plane  and  the  orbit  plane 

at  the  ascending  node.  The  argument  of  perigee,  u,  is  the  angle  measured  in 

the  plane  of  the  orbit  defined  by  the  ascending  node  and  the  periapsis  (the 

point  of  the  satellite's  closest  approach  to  the  center  of  the  earth).  The 

mean  anomaly,  M,  indicates  the  satellite's  position  in  its  orbit.  The  mean 

motion,  n,  measured  in  revolutions  per  day,  contains  information  about  the 

period  of  the  orbit  and  the  semi-major  axis  of  the  orbit  ellipse.  The 
•  •  • 

quantities  and  -g-  are  the  first  and  second  time  derivatives  of  the  mean 
motion,  respectively. 
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3. 2. 4. 2  Calculation  of  Satellite  Position 

Given  a  satellite  orbital  element  set,  the  algorithm  to  calculate  the 
satellite's  EC1  position  and  velocity  vectors,  X  and  i,  for  A  t  from  epoch 
time,  Tg,  begins  by  calculating  the  value  of  the  semi-major  axis  (in  earth 
radii)  at  epoch. 

a  \  (1  +  4  6-  4fi2> 

v  ri 

where 

-  I  (1-4  sin2  i) 

5  i  _ 2  2 _ £ _ 

(  JL  ,f(1  -  e2)2 
n  d 


y  =  gravitational  constant  of  the  earth 
=  398600.5  km^/sec2 

=  second  zonal  harmonic  coefficient  of  the  geopotential  function 
=  0.00108248 


Next,  the  secular  perturbations  are  introduced. 


n  cos  1 
QSQ  _  £ _ £ _ 

0  a2  <1  -  .*>* 


at 


U>  =  U>  + 

o 


|  J2  n  <2  -  I 


sin2  i) 


a2(1  -  e2)2 


At 


where  °0  an<*  “o  are  unPerturbed  values  of  the  orbited  element  set,  and 
ft  and  to  are  the  perturbed  values.  Then  the  eccentric  anomaly,  E,  is  solved 
for,  using  the  Newton-Raphson  iteration  method  for  Kepler's  equation. 


M  =  E  -  e  sin  E 

for 

M  =  M  +  n  A  t  +  §  At2 

O  c. 


where  Mq  is  the  mean  anomaly  at  time  t  =  T£  and  M  is  the  mean  anomaly  at  time 
t  =  T£  +  At.  The  following  are  solved  for: 

L  (true  argument  of  latitude)  =  2  tan ~\J~\  -  e  tan  §  ♦  “ 

R  (range)  =  a  (1  -  e  cos  E) 

y  a  sin  E 

Rv  (transverse  component  of  velocity  vector)  = 


V  P  a  (1  -  e2) 

R 


R  (radial  component  of  velocity  vector)  =  -y 


Defining  unit  vectors  U  in  the  radial  direction  and  V  perpendicular  to 
the  radial  vector  in  the  direction  of  the  transverse  component  as 


! 
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fu*\ 

cos  L  cos  ft  -  sin  L  sin  ft  cos  i| 

u  = 

uv  r 

cos  L  sin  ft  4-  sin  L  cos  ft  cos  i] 

■» 

luy 

[  sin  L  sin  i  / 

*  z* 

V 

•» 


-sin  L  cos  ft  -  cos  L  sin  ft  cos  i 
-sin  L  sin  ft  +  cos  L  cos  ft  cos  i 
cos  L  sin  i 


we  have 


3.3  SPACE  OBJECT  GROUND  TRACE 


The  orbital  element  set  can  be  used  to  calculate  space  object  ground 
traces.  This  section  presents  algorithms  for  calculating  the  ground  traces  of 
satellites  and  ballistic  missiles. 

3.3.1  Satellite  Ground  Trace 


The  satellite  ground  trace  is  the  locus  of  points  described  by  the 

satellite  sub-orbital  over  a  given  time  period  j  t  :  E  At..  Given  a 

i  1 

satellite's  position,  the  satellite  sub-orbital  is  defined  as  the  point  of 
intersection  of  the  line  through  the  satellite  position  perpendicular  to  the 


3-17 


reference  ellipsoid  with  the  ellipsoid.  Given  a  set  of  A  t.  from  epoch  T_, 

*  E> 

•  •  • 

and  the  orbital  element  set,  (T^,  n  e,  i,  w  M,  n,  -^-)t  the  set  of 
geocentric  ground  trace  points  to  be  plotted  may  be  generated  by  the  methods 
of  Section  3.2. 4.2  followed  by  the  transformation  of  Section  3. 2. 2. 3  for  each 


Dividing  the  time  span  desired  into  equal  time  segments  is  instructive  in 
that  the  ground  distances  drawn  indicate  the  proportion  of  time  each  area  of 
the  earth  is  under  surveillance.  The  set  of  ground  trace  points  generated 
this  way  do  not  produce  smooth  curves  for  non-circular  orbits,  however.  The 
following  algorithm  generates  a  set  of  A  t ^  such  that  the  ground  coverage 
distances  plotted  will  be  approximately  equal  in  length. 

The  true  anomaly,  v,  is  the  central  angle  from  periapsis  to  the 
satellite's  position.  Obviously,  dividing  360°  into  N  equal  true  anomaly 
angles  implies  that  equal  ground  distances  will  be  covered  on  a  spherical 
earth  (See  Figure  3-5).  However,  the  expression  which  will  generate  the  A^ 
is  in  terms  of  the  eccentric  anomaly  E.  The  eccentric  anomaly  is  defined  as 
the  angle  (measured  from  the  center  of  the  earth)  between  the  periapsis  and 
the  intersection  of  the  circle  circumscribing  the  orbit  ellipse  with  the  line 
through  the  satellite  perpendicular  to  the  semi-major  axis  (See  Figure  3-6). 
The  relationship  between  v  and  E  is  given  on  page  39  in  reference  [2]  by 

tan  2  =  *\  T  -+  eC  tan  I 


and  the  A  t^  is  given  on  page  1  of  the  same  reference  by 


A 


2 


-  e  sin 


2 


cos 


Figure  3-5  Using  Equal  True  Anomalies  to  Produce  Equal  Ground  Distances 


Figure  3-6  Definition  of  Eccentric  Anomaly 


The  algorithm  proceeds  as  follows: 

1.  Find  the  eccentric  anomaly  of  the  satellite  at  the  start  time  by  the 
method  of  Section  3.2.4. 2,  0°  <  E  <  360° 

2.  Calculate  the  corresponding  true  anomaly  as 


3. 


4. 


v0  *  2  tan-1[«yjyi^i  tan  I  3 

Let  A  v  be  the  increment  of  true  anomaly.  Then  the  table  of  true 
anomalies  may  be  generated  as 

v  =»•  +  i*  A  v  ,  i  =  0  to  H. 

1  o 

The  corresponding  table  of  eccentric  anomalies  is  generated  as 

— -  v 

=  2  tan"1  -j-~§  tan  ]  .  i  =  0  to  N 


5.  Finally,  the  tables  of  A  may  be  calculated  as 


Ei  "  Ei-1  Ei  “  Ei-1 

2  (--1  ■  ■  -1  -  -  e  sin  '-4  —  cos 


Ati  «~ 
for  i  :  1  to  N, 


3.3.2  Ballistic  Missile  Ground  Trace 


The  ground  trace  of  a  ballistic  missile  defined  by  (Tg,  I},  e,  i,u>) 
launched  at  location  L  (  \  ,  <f>  ,  h)  requires  the  algorithms  described  in  this 
section.  If  the  predicted  point  of  impact  is  known  (say  from  TSATS),  then  the 
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beginning  and  end  points  are  known.  If  the  predicted  point  of  impact  is  not 
known,  then  it  must  be  estimated  as  follows. 

As  explained  in  reference  [13  on  pages  279  -  297,  the  orbit  of  a 
ballistic  missile  is  an  ellipse  in  its  non-powered  phase.  Due  to  propulsion 
forces  and  atmospheric  and  gravitational  effects,  this  is  not  true  before 
burnout  and  after  reentry  (See  Figure  3-7).  However,  the  free-flight 
trajectory  is  symmetrical,  and  half  of  the  free-flight  range  angle,  V  ,  lies  on 
each  side  of  the  semi-major  axis.  Since  no  time  of  burnout  and  time  of 
reentry  information  is  available,  the  assumption  is  made  that  the  complete 
ballistic  path  is  a  part'  of  an  ellipse  symmetric  about  the  semi-major  axis. 

The  true  anomaly,  v  ,  is  calculated  to  the  point  of  launch.  The  true 

s  - 

anomaly,  v  iS  calculated  to  the  predicted  point  of  impact  (if  known),  or  to 

be  360°  -  v  otherwise.  Values  for  the  semi-major  axis  and  mean  motion  are 
s 

calculated,  appropriate  A  are  calculated,  and  then  the  method  of  Section 
3. 2. 4. 2  followed  by  the  transformation  of  Section  3. 2. 2. 3  is  used  to  generate 
the  ground  trace  points. 

The  launch  point  true  anomaly  v  is  calculated  as  follows.  Let  LP  be 

®  ^ 

the  vector  in  ECI  coordinates  of  the  launch  point.  LP  is  calculated  by  the 

— ^ 

transformation  of  Section  3.2. 2. 2.  Let  P  be  the  vector  in  ECI  coordinates  of 
periapsis.  As  defined  on  page  77  in  reference  [33, 

cos  uu  cos  U-  sin  n  sin  u>  cos  i\ 

P  =  cos  uu  sin  +  sin  ft  cos  u>  cos  i  I 

->  sin  u  sin  i  J 

Then, 
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Figure  3-7  Ballistic  Missile  Trajectory 
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-1 
cos  • 


P  • 
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LP 
— ) 


LP 
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The  equations  on  page  20,  r  s 
oos  v=  --c~sCg3_E|,  in  reference  [1],  may  be 
and  the  eccentric  anomaly  at  the  launch  point 


a  (1  - 


e2) 


and 


page  187, 


1  -  e  cos  v 
solved  for  the  semi -major  axis  a 


S* 


a 


LP 

(1  -  e  cos  v  ) 

s 

,  e  +  cos 

-1  ,  s  , 

003  V } 

i  +  e  cos  v 

s 


The  ballistic  missile  element  set  may  be  extended  to  an  orbital 


letting  M  =  E  -  e  sin  E 

3  S 


and 


where  jj  is  the 


constant  of  the  earth,  and  by  setting  and  -g-  to  zero. 


element  set  by 
gravitational 


Defining  4  n  to  be  (n„  -  nj  /  (N  -  1)  if  the  predicted  impact  point  is 

S  V 

known,  and  to  be  (360°  -  2vfl)  /  (N  -  1)  otherwise,  the  A  t^  are  calculated  in 
the  same  manner  as  Section  3.3.1,  steps  3  to  5. 


3.«  RADAR  RELATED  PROBLEMS 


The  radar  position  (X,  <f>,  h)  and  coverage  limits  (R,  An,  A^,  Em,  E^)  are 
stored  in  the  SABERS  data  base  for  each  radar.  The  coverage  limits  are  the 
range  R,  minimum  and  maximum  azimuth  An  and  A^,  and  the  minimum  and  maximum 
elevation,  Effl  and  E^.  As  shown  in  Figure  3-8,  azimuth  is  measured  clockwise 
from  local  north,  and  elevation  is  measured  from  the  horizon,  positive  above 
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Radar  Coverage  Limits 


the  horizon  and  negative  below  the  horizon.  The  azimuth  limits  are 
0°  <  A  <  360°  and  the  elevation  limits  are  E  <  E  <  90°.  In  practice,  E  is 
limited  to  values  greater  than  five  or  ten  degrees  due  to  refraction  effects. 

3.^.1  Radar  Coverage  Plots 


Elevation  information  is  lost  in  graphically  representing  extents,  and 
the  range  information  is  distorted.  This  is  due  to  the  method  chosen  to 
represent  the  radar  coverages,  which  is  to  project  points  on  the  radar  beam 
periphery  onto  the  surface  of  the  earth.  The  set  of  points  to  be  plotted  is 
projected  from  ECI  coordinates  by  the  transformation  of  Section  3.2.2. 3.  The 
set  of  ECI  points  is  generated  by  the  following  algorithm. 


/e\ 

sin 

A\ 

n 

=  cos 

A 

lu/ 

0 

/ 

In  the  local  topocentric  coordinate  system,  the  unit  vector  defined  by 
the  azimuth  is 

matrix  G  described  in  Section  3.2.3,  this  unit  vector  in  the  ECI  coordinate 

system  is  X  =  |  y  |  a  GT  I  n )  .  The  point  on  the  radar  beam  at  range  R  +  A  R 

•»  \zl  \ul 

for  any  azimuth  in  ECI  coordinates  is  then  P  =  L  +  (R  +  &  R)  X,  where  L  is 

the  radar  site  position  in  ECI  coordinates  obtained  by  the  transformation  of 
Section  3. 2. 2. 2. 


In  order  to  show  the  effect  of  the  curvature  of  the  earth  on  the  radar 

coverage  picture,  only  3/5  of  the  points  to  be  plotted  are  calculated  at  each 

A  A  with  range  R.  For  A  =  A_  and  A  =  AM,  1/5  of  the  points  to  be  plotted  are 

in  n 

calculated  by  letting  A  R  vary  from  -R  to  0. 


3. '1. 2  Radar  Coverage  of  a  Satellite 

Given  a  particular  geometry,  it  is  straightforward  to  determine  if  a 
satellite  is  under  radar  coverage  by  comparing  the  actual  range,  azimuth,  and 
elevation  to  the  satellite  with  the  radar  limits.  As  shown  in  Figure  3-9,  the 
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azimuth  and  elevation  angles  are  defined  in  the  local  topocentric  coordinate 
system  by 


El  =  sin_1(5u)  -90°  <  El  <  90° 

Az  =  tan"^— 1~)  0°  <  Az  <  360° 


l&e\ 

where  6n  is  the  direction  cosine  vector  from  the  radar  site  to  the  satellite 

\&ul 

position. 


In  ECI  coordinates,  the  range  p  to  the  satellite  from  the  radar  is 


P 


-  XR>2  *  (IS 


-  V2  *  (ZS 


where  X  is  the  satellite  position  calculated  by  the  method  of  Section 
->S 

3.2. 4. 2  and  X  is  the  radar  position  calculated  by  the  transformation  of 
■>R  X  -  X 


Section  3. 2. 2. 2.  The  direction  cosine  vector  is  then 


-»S  *R 


in  ECI 


coordinates.  By  the  transformation  matrix  G  of  Section  3.2.3,  we  may  then 
calculate  the  local  topocentric  direction  cosine  vector  as 
and  calculate  El  and  Az. 


6  e\  i 

(6x\ 

6  n  1  =  G 

i  y  I 

\5u/  ! 

l6'2/ 

To  graphically  represent  the  radar  coverage  for  which  the  satellite  is 
visible,  the  method  of  Section  3.4.1  may  be  used.  The  azimuth  angles  at 
fcstart  and  fcend  rePlace  fche  radar  Unit  angles  Am  and  AM> 


3. 4. 2.1  Time  of  Coverage  Calculations 


If  the  satellite  is  in  coverage  at  times  t^  and  t^,  and  out  of  coverage 
at  times  t^  and  t^+1 ,  it  is  known  that  the  satellite  first  becomes  visible 
at  some  time  between  t^_1  and  t^,  and  passes  out  of  coverage  at  some  time 
between  tj  and  tj+^.  These  exact  times  are  approximated  by  t^  1  and  t.+.j,  so 
that  the  satellite  is  considered  under  radar  coverage  over  the  larger  time 
interval.  Greater  accuracy  may  be  gained  by  using  a  smaller  time  interval. 

3. 4. 2. 2  Exceptions  to  Coverage  Cheeks 

Checks  for  coverage  need  not  be  performed  for  those  geometries  for  which 
the  ground  trace  of  the  satellite  is  in  the  opposite  hemisphere  from  the  radar 
site  (see  Figure  3-10).  Ho  checks  need  to  be  performed  at  all  if  the 
satellite's  minimum  height  above  the  reference  ellipsoid  (that  is,  at 
periapsis)  is  larger  than  the  radar  range  limit  R  (see  Figure  3-11).  This 
means  there  is  no  check  if  R  <  a  (1  -  e)  -  agl  for  an  orbit  with  semi-major 
axis  a  and  eccentricity  e  and  earth  semi-major  axis  ae  . 

3.  **.2. 3  Pass  Through  Coverage  Check 

In  the  discrete  method  of  Section  3.4.2,  it  is  possible  for  the  satellite 
to  be  reported  as  out  of  coverage,  when  for  some  time  interval  inside  the  time 
step  size  the  satellite  may  have  passed  through  radar  coverage  (see  Figure  3- 
12).  As  implied  by  the  terminology  "passed  through,"  this  condition  may  be 
checked  for  by  comparing  the  relations  between  the  actual  values  and  the 
limits  at  the  two  discrete  time  points  whenever  the  time  step  size  is  much 
smaller  than  the  period  of  the  satellite,  Tp.  If  the  elevation  angles 
measured  at  time  t^  and  t^  are  both  less  than  E^,  or  both  greater  than  E^, 
then  there  has  been  no  pass  through.  Similarly,  if  the  two  measured  azimuth 
angles  are  both  less  than  A^  or  greater  than  A^,  there  has  been  no  pass 
through.  Finally,  if  the  ranges  measured  at  time  t^  and  ti+1  are  both  greater 
than  the  range  limit,  and  the  satellite  has  not  passed  through  periapsis,  then 

there  has  been  no  pass  through.  ' 
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Satellite  can  not  ba  | 
visible  it  the  suborbital  \ 
Is  not  in  the  same  \ 
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if  the  suborbital  Is  in  the 
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the  radar. 


Figure  3-10  Hemisphere  Checking 
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Figure  3-11  Radar  Range  Insufficient  for  Coverage 


periapsls  =  a(1-e) 


SATELLITE 


ripure  3-12  Satellite  Passing  Through  Radar  Coverage 


The  satellite  nay  pass  through  radar  coverage  when  the  ground  trace 
crosses  from  the  different  hemisphere  to  the  same  hemisphere  as  the  radar 
site.  This  means  that  the  check  values  are  calculated  for  the  first  and  last 
times  for  which  the  satellite  is  in  the  opposite  hemisphere. 

3.5  PHOTO  RECONNAISSANCE  PROBLEM 

The  satellite  in  orbit  may  carry  a  camera  mounted  in  such  a  position  that 
a  portion  of  the  earth's  surface  will  be  under  reconnaissance  coverage.  In 
SABERS,  the  camera  aperture  is  defined  by  the  field  of  view  angle  ¥  ,  Figure 
3-13.  The  camera  mounting  is  defined  by  two  angles:  the  azimuth  (from  local 
north),  Az,  and  elevation  (from  down),  El,  both  measured  from  the  axis  of  the 
cone.  If  the  elevation  angle  is  zero,  then  the  cone  axis  intersects  the 
ground  trace  point  of  the  satellite.  This  follows  from  the  definition  of  the 
satellite  sub-orbital  in  Section  3.3.1. 

3.5.1  Photo  Recconaissance  Plots 


Drawing  the  coverage  of  the  camera  requires  the  solution  of  the 
intersection  of  the  oblique  cone  with  the  reference  ellipsoid.  The  algorithm 
is  developed  for  two  cases:  El  s  0  and  El  4  0. 

3.5. 1.1  Case  1:  El  =  0 

As  described  in  pages  4-424  to  4-425  in  reference  [6]  the  intersection  of 
the  ECI  vector 

X  :  S  +  P  P,  (3-2) 


where 


3-33 


3-34 


X 


is  the  vector  to  the  point  of  intersection 


r\ 

S  J  Sol  is  the  position  vector  of  the  satellite 

*  \s  j 


P  =  slant  range 


P 

-> 


is  the  line  of  sight  vector 


(see  Figure  3-1*0 


and  the  reference  ellipsoid 


x 


2 


1 


(3-3) 


yields  the  two  solutions  for  the  slant  range: 
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P  = 


-B  ± 


2A 


4AC 


(3-4) 


where 


A  = 


p2  +  P2 
P1  2 


f| 

b2 

e 


B  = 


2  S1  P1  +  2 


S2  P2 


2  S,  P 


3  3 


C  = 


S?  + 


♦  -  1 


where  a  is  the  semi-major  axis  of  the  earth  and  is  the  semi-minor  axis  of 
the  earth.  The  minimum  of  the  two  roots  is  used  to  ensure  that  the  solution 

X  is  the  point  in  the  same  hemisphere  as  the  satellite  ground  trace. 

* 


At  time  t,  the  satellite  position  vector  S  is  known  by  the  method  of 

Section  3. 2. *1.2.  As  mentioned  in  Section  3.5,  the  cone  axis  is  coincident 
with  the  ground  trace  vector.  In  the  local  topocentric  coordinate  system,  the 

cone  axis  direction  cosine  vector  is  then  (n)  s  (  o]  •  The  ECI  cone  axis 

U  /  1-1/ 

direction  cosine  vector  R  is  then 


*  T 

R  =  GT  0  , 

i — 1 
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where  G  is  the  transformation  matrix  defined  in  Section  3*3.  Given  any  unit 

A  A 

vector  U  normal  to  R  ,  the  line  of  sight  vector  P  on  the  surface  of  the  cone 


is  then  defined  by 


A  A 

P  s  R  cos  a  +  U  sin  a 


where  a  =  1  is  the  angle  of  the  cone  measured  from  the  cone  axis  (see  Figure 
3-15). 


Many  such  vectors  U  may  be  generated  by  considering  the  local  topocentric 


vectors 


/sin  Aj 
=  (cos  A. 


centered  at  the  satellite  position  where  the  A^^ 


constitute  a  set  of  azimuth  angles  from  A^  =  0°  to  A^  =  360°,  measured  from 
north.  The  set  of  EC1  vectors  normal  to  R  is  then 


A 


Isin  A A 
cos  k^  I  . 
0  / 


Since  S  and  P  are  known,  the  slant  range  o  nay  be  solved  for  by  the  method 
■> 

of  Section  3.5. 1.1,  upon  which  X  is  known  in  ECI  coordinates.  Then  X  may 

->i  -M 

be  plotted  in  geocentric  coordinates  by  the  transformation  of  Section  3. 2. 2. 3. 

o 

If  P  does  not  intersect  the  earth,  then  B  -  MAC  <0  and  the  roots  of  the 

quadratic  equation  (3-M)  will  be  complex.  In  this  case,  consider  the  line  of 
sight  vector  P 
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P  =  R  cos  B  +  U  sin  6 
4 


such  that  P  is  tangent  to  the  earth  surface.  The  angle  B  such  that 

■>  2 
tangent  may  be  solved  for  by  setting  the  discriminant  B  —  4AC  -  0.  Define 

the  earth  ellipsoid  equation  (3-3)  as 


2  2  2  2  4tu  *  e 

x  +y  +Dz  a  a  ,  with  D  a  — = 

e  bc 

e 


Then  by  substituting  (3-2),  we  have 


(S1  +  P  P^2  +  (S2  ♦  p  P2)2  ♦  D  (S3  +  P  P3)2  a  a2 


»2<p2.pf.Dp|>.P  (IS,  P,.2S2P2 


♦  2  D  S3  P3)  ♦  S*  ,  S2  *  D  Sj  -  .  0 


where  S  is  constant  (the  satellite  position)  and 


P  a  R  cos  B  +  U  sin  B 
-> 


Letting 


~  ;•  --  -  -  i[[ — . i  n —  r~  ~  ~i~n  mr~  Kignpm 


Pj  *  r2  cos2  B  +  2  Uj  cos  B  sin  B  ♦  u2  sin2  & 

2  2 
Pi  PJ  =  rirJ  008  0  +  <ri  UJ  ♦  rj  ui>  008  6  sin  6  ♦  «4  Uj  sin  6 

This  means  that  equation  (3-5)  becomes,  by  substitution, 

X  cos2  B  +  Y  cos  3  sin  B  +  2  sin2  B  =  0 


where 


X  = 


Vi  ♦  Vs  * 


V3r3  *  Vlr2  * 


v5r,r3  . 


'6r2r3 


Y  a  2Viriui  +  2V2r2u2  ♦  ♦  V1|(r1u2  +  r^) 

*  V5^r1u3  +  r3u1J  +  V6*r2u3  *  r3u2) 


Z  = 


V?  * 


Vs  * 


v3“3  * 


Vlu2 


V5U1U3  “  V6U2U3 


vi  *  si  - c 
V2  *  S2  -  C 


V3  :  D  (0  S‘  - 

v4  5  2  si  s2 

V2DS1S3 

V6  =  2  D  S2  S3 


C) 


Dividing  (3-6)  by  cos2  3 


we  have  a  quadratic  in  tan  3 


(3-6) 
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Z  tan2  0  +  Y  tan  0  ♦  X  a  0 


or 

tan  0  s 

No  solution  for  0  exists  if  Z  =  0  or  Y2  <  4XZ.  This  will  oceur  if  the  R  x  U 
plane  does  not  intersect  the  earth. 

Choosing  the  larger  of  the  two  roots  to  get  positive  0 ,  find 

cos  3  =  (1  ♦  tan2  0  J"1 
sin  0  a  tan  0  cos  0. 


This  gives 


A  A 

P  a  R  cos  3  +  U  sin  0 
*T 


where 


P 

*T 


is  the  line  of  sight  to  the  point  of  tangency 


Therefore, 
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F 


a  =  p;  +  p;  ♦  d  p; 

1  l2  *3 

B  =  2  S  p  +  2  S2  P  +  2  D  S  P 

1  l2  5  *3 


and 


The  resultant  X  may  be  plotted  in  geocentric  coordinates  by  the 
-»T 

transformation  of  Section  3.2.2. 3 

r  • 


3.5. 1.2  Case  II,  El  i  0 


— f 

Let  R  be  the  vector  along  the  cone  axis.  In  the  local  topocentric 
coordinate  system. 


/e1 

sin  El  sin  Az\ 

R  =  n 

S 

sin  El  cos  Az 

lu, 

-cos  El  1 

Note  that  if  El  =  0°,  R* 


as  before. 


It  is  desirable  to  define  two  mutually  perpendicular  vectors 

_  i  _• 

perpendicular  to  R  to  form  a  new  coordinate  system  with  R  as  one  axis. 
Define: 


3— *1*1 


I 


E  = 


R  X  N 
IR1  x  N| 


J 

4 


k 

-> 

r3 

0 


»r,  i  ♦  r.  k 
3  -»  1  -> 


r3  +  r1 


and 


i  — t 

'  .  E  x  B 


N  s 


t  — « 

IE  x  R  I 


i 

-» 


-r- 


2  2 
r3+r1 


j 

•» 


k 


♦  n. 


2  2 

-r1  r2  i  ♦  (r,  ♦  r,)  j  -  r9  r,  k 


2  '3 


4 


22  ,2  2x2  2  2 

r1  r2  +  <r1  ♦  rp  *  r2  r3 


noting  that  if  El  =  0,  then  E  =  |  oj  =  E  and  N  =  |  l|=  N.  Now  define 

U  t  *  N  cos  9i  ♦  E  sin  8^  for  0B  <  8^  _<  360  ,  to  provide  a  rotating  systea  of 
cone  surface  rays  similar  to  before. 

—  TUI 

As  before,  the  vectors  may  be  expressed  in  ECI  coordinates  as  R  *  G  R 

—  T—  • 

and  II  :  G  0  ,  for  the  transformation  matrix  G  defined  in  Section  3.2. 3.  and  we 
may  calculate  P  =  R  cos  a  ♦  U  sin  a  for  the  line  of  sight  vector  in  ECI 
coordinates. 


At  this  point,  it  is  convenient  to  f: 

-  T  1° 

contained  in  the  plane  defined  by  It  :  G  0 

H 


nd  the  U  vector  such  that  P  is 

A 

and  U.  This  is  simply 
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u  = 


F  -  R  cos  £ 
sin? 


where  £  is  the  angle  between  R  and  P  defined  by 


cos  £  = 


The  point  X  may  then  be  found  by  the  method  of  El  a  0,  where  the  field  of  view 
angle  a  is  replaced  by  £ . 

3.5.2  Special  Conditions 

There  are  special  conditions  to  be  considered  when  the  cone  axis  does  not 
intersect  the  earth.  There  are  no  computational  problems  when  the  cone  axis 
does  intersect  the  earth. 

3.5.2. 1  Determining  If  the  Cone  Intersects  the  Earth 

As  shown  in  Figure  3-16,  the  cone  may  not  intersect  the  earth  or  may 
envelop  the  earth.  Since  the  algorithm  described  in  Section  3.5. 1.2  will 
return  all  the  tangents,  only  the  case  of  no  intersection  must  be  detected 
independently. 

The  cone  will  not  intersect  the  earth  if  the  angle  between  the  cone  axis 
and  the  vector  to  the  center  of  the  earth,  9,  is  larger  than  the  field  of 
view  angle,  a  ,  and  the  angle  to  the  tangent  vector,  6,  from  the  ray  to  the 
center  of  the  earth,  i.e.  0  >  a  +  6  . 

Let  R  be  the  cone  axis  vector  in  ECI  coordinates,  and  S  be  the  satellite 

•> 

position  derived  by  the  method  of  Section  3.2.11.2.  Let  P  be  the  vector 

-»T 
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tangent  to  the  earth's  surface 


Then 


cos  8 


and 


sin  3  s  \f"  p  _ 

1  -  COS*  p 

also, 

R  «  -S 

cos  6  =  - — 

S 

; 

There  is  no  intersection  if  0  >  a  8  ,  that  is,  if 

cos  0  <  cos  a  cos  8  -  sin  ot  sin  8  . 


3* 5. 2. 2  Removing  Excess  Points 


As  shown  in  Figure  3-17,  some  of  the  points  of  tangency  should  r.ot  be 
plotted  in  case  the  point  of  tangency  is  not  in  the  cone  coverage.  This  is 
detected  by  noting  that  the  angle,  6  ,  between  the  tangent  ray  P  and  the  cone 
axis  U  is  larger  than  the  field  of  view  angle  a  .  That  is: 
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e  >  a 


(b) 


RESULTANT 

COVERAGE 

AREA 


EXCESS  s 
REMOVED/ 


%  EXCESS 
SREMOVED 

\ 


Figure  3-17  Points  of  Tangency  Not  in  Cone  Coverage 


cos  6  <  cos  a. 


or 


cos  a 


> 


|  P 1 1 R  | 


3.5.3  Time  of  Coverage  Calculations 

Approximations  are  performed  in  calculating  the  times  of  coverage  of  a 
point  of  interest  on  the  ground  by  the  reconnaissance  satellite.  These 
approximations  result  in  the  algorithm  producing  times  of  coverage  that  span 
the  actual  times  of  coverage.  At  each  time  step,  the  points  of  intersection 
may  be  determined  by  the  method  of  Section  3.5.2.  The  figure  determined  by 
these  points  of  intersection  is  approximated  by  a  circle  on  the  surface  of  the 
earth  circumscribing  the  figure.  The  center  of  the  circle  is  the  average  of 
all  the  points  in  the  figure,  and  the  radius  of  the  circle  is  taken  as  the 
largest  of  the  great  circle  distances  from  the  center  point  to  the  figure 
vertices.  The  great  circle  distance  formula  between  two  points  ( A  ^ ,  <(>  1 ,  h^ 
and  (\2,  $  ,  h2)  is 

r  =  ag  cos-1  (sin  ^  sin  $2  ♦  cos  ^  cos  $  2  cos  (*.,  -  a2>), 

where  a  is  the  semi-major  axis  of  the  earth, 
e 

3.5.3. 1  Pass  Over  Coverage  Check 

To  check  against  coverage  between  the  discrete  time  steps,  the  following 
method  is  used.  Let  the  two  figure  center  points  be  CP1  =  ^  ,h.j)  and 

cp2  =  <X2»  <p 2’  l12^’  Calculate  the  two  radii  of  coverage  r^  and  r2  with  the 
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1 


great  circle  distance  formula.  Let  r  s  max(r^(  rg).  It  is  necessary  to 
compare  r  with  the  minimum  distance  from  the  center  point  trace  to  the  ground 
point  of  interest,  P  =  (Xp,  4>p,  hp). 

From  spherical  trigonometry,  (See  Figure  3-18), 


cos 

a 

=  sin 

♦l 

sin 

♦2 

♦ 

cos 

*1 

cos 

♦2 

cos 

(X1  - 

V 

cos 

b 

s  sin 

sin 

♦ 

cos 

*1 

cos 

V 

cos 

<A1  - 

V 

cos 

c 

s  sin 

*2 

sin 

+ 

cos 

*2 

cos 

* 

p 

cos 

(X2  " 

V 

and 


cos  c  =  cos  a  cos  b  +  sin  a  sin  b  cos  8 


(3-7) 


where  B  is  the  included  angle  between  sides  a  and  b.  It  is  desirable  to  find 
0  <  y  1  such  that 

c  *  cos-1  (cos  (  ya)  cos  b  ♦  sin  ( Y  a)  sin  B  cos  B) 


is  minimum. 
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Let 


dc  d  cos~'(u) 

j_.  s - - - -  (  _sin  ( y  a)  C08  b  +  eoa  (y  a)  ain  t>  cos  ft)  *  0. 

Since 

a-Sgg’V).  .  .  u2)1/2  t  0, 

we  have 

-sin  (y  a)  cos  b  +  cos  (  Ya)  sin  b  cos  ft  a  0 

sin  (  Ya)  cos  b  a  cos  <  Ya)  sin  b  cos  ft 

tan  (  Ya)  a  tan  b  cos  ft 

Y  s  tan-1  (tan  b  cos  ft ) 
a 

Let  a  a  Y  a  for  0  <  y  <  1 ,  and  then  find 

dab  cos-1  (cos  a'  cos  b  +  sin  a'  sin  b  cos  ft) 

€ 


with  b^  a  earth  semi -major  axis.  It  is  not  necessary  to  find  g  explicitly, 
since 


Sin  b  oos  0  a  S9JLS.-OOS  a  cos_b 

sin  a 


from  (3-7).  Also,  if  a  a  sin  a  a  0,  let  d  =  b  cos-1  (max  (cos  b,  cos  c)). 

e 

If  d  <  r,  then  the  ground  point  is  considered  to  be  under  coverage  by  the 
reconnaissance  satellite. 
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3.5. 3.2  Coverage  Time  Interval  Accuracy 


The  set  of  all  times  such  that  d  <  r  for  time  pairs  (t^  y  t^) , 
(tj  tj+1)  is  reported  as  start,  end  times  (t^  tj+1).  This  is  similar  to 
the  method  described  in  Section  3.4.2. 1.  However,  there  is  a  limit  to  the 
accuracy  of  this  algorithm,  due  to  approximating  non-circular  figures  with 

circles.  To  ensure  that  the  error  is  on  the  side  of  caution,  the  d  calculated 

a. 

in  Section  3.5.3. 1  is  multiplied  by  -g—  i  1.0034  as  a  model  correction 

e 

factor . 

3.6  THREAT  WINDOW  ALGORITHM 

The  determination  of  launch  windows  (times  at  which  a  payload  may  be 
launched  from  a  site  to  intercept  a  target  satellite  in  its  orbit)  is  based  on 
LPRE,  a  launch  prediction  algorithm  described  on  pages  2-11  to  2-17  in 
reference  [7]. 

3.6.1  Existing  LPRE  Formulation 


The  empirical  formulas  provided  in  the  reference  are  functions  of  the 
target  orbital  period,  Tp,  and  the  phase  angle  <{> .  The  phase  angle  is  defined 
as  the  angle  at  the  center  of  the  earth  between  the  target  satellite  position 
and  the  launch  site  position  at  the  time,  tp,  when  the  site  is  coplanar  with 
the  orbit. 

Letting  t  s  window  open  time,  t  =  window  close  time  and  t  =  nominal 
o  c  n 

launch  time,  the  following  regions  have  been  identified: 
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Region  1 


0°  <  <fr  <  60° 


Region  2: 


*  t. 


T 

P 


♦  <  0° 

-  •«  Tp  • 

_  60°  ♦  ♦  T 
360°  p‘ 


-42°  < 


-60°  < 


$ 

4>  <  -42* 


t  st  ,  t  *J3£L  t 

c  P  360°  p 


ln!V  *05  TP 


-180°  <  ♦  <  -60° 
v  -  *  .  ♦.  ♦-60°  T 


Region  3 


Region  4: 


. ""T 


60°  <  <J>  <  180° 


not  viable 


3.6.2  Determining  Time  of  Coplanariti 


Finding  t^,  the  time  of  coplanarity,  is  accomplished  in  an  Iterative 
fashion.  There  will  be  a  maximum  of  two  times  of  coplanarity  in  one  day,  and 
a  minimum  of  no  times  of  coplanarity  (in  case  the  launch  site  latitude  is 
larger  than  the  orbit  plane  inclination).  Therefore,  there  are  at  most  two 
launch  windows  for  a  given  launch  site  and  orbit  plane  in  one  day. 

For  launch  site  (A,  <f>,  h)  and  satellite  position  S  and  velocity  V,  at 

■> 

current  time,  t,  in  seconds  since  midnight,  define  the  ECI  coordinates  of  the 
launch  site  as 


(i)'P 


G.j  cos  <t>  cos  0 
G1  cos  #  sin  6 
Gg  sin  # 


(3-8) 


where  6  is  the  hour  angle  of  section  3.2.2. 1  at  t. 


G1  =  h  + 


Gg  *  h  + 


1  -  (2f  -  f2)  sin2# 


ae(1  -  f)‘ 

1  -  (2f  -  f2)sin2< 
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ae  2  6378.16  km.  s  semi-major  axis  of  the  earth 

f  -  1 

f  "  7W& 

(see  page  115  of  reference  C 3 3 ) ,  and  denote  the  orbital  plane  as 


a'x  +  b'y  c'z  +  d’  =  0 


when 


S  x  V 

(A*,  B*.  C*)  s  — - ~  and  D*  s  0 

IS  x  V 
■>  -> 


Substituting  (3-8)  into  (3-9),  we  have 

A  cos  8  +  B  sir.  6  +  C  s  0 

for 

A  s  A  G.j  cos  0,  B  =  B  G.j  cos  and  C  =  C  sin  ♦ . 

Solve  for  the  true  roots  of  (3-10)  from  among  the  four  solutions  to 


-M, i  °\1  A2  ♦ 

A2  ♦  B2 


6=  sir.’1  -?<?  Z  CJ 

A2  +  B2 


(3-9) 


(3-10) 
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and  for  each  true  root,  find  t^  (tine  aince  midnight)  as 


fci  s 


e. x  _ e 

IE 

dt 


where 


s  Greenwich  hour  angle  at  midnight 
o 


and 


d0 

dt 


s  earth's  rate  of  rotation 


Using  t^  as  the  current  time, 
refine  the  estimate  of  t.  until 


adjusted  values  for  S  and  V  may  be  used  to 


<  e 


Then  the  phase  angles 


for  each  t  are  calculated  as 
1  P 


S  «L 

-1,  ->i  -M  4 
cos  ( - ) 


s 

L 

->i 

-M 

where  S  and  L  are  the  ECI  positions  of  the  satellite  and  launch  site  at 
■M  -»i 
time  t^. 


3.7  HAP  PROJECTIONS 


In  this  section,  the  formulae  required  to  perform  the  SABERS  map  drawing 
functions  will  be  presented.  These  formulae  permit  the  translation  of  a  point 
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or  series  of  points  on  the  earth's  surface,  represented  by  latitude  and 
longitude,  to  X  and  Y  values  for  plotting  on  a  Cartesian  coordinate  system. 

There  are  two  basic  steps  in  this  conversion.  First,  a  scale  factor  must 
be  calculated.  This  value  is  based  on  the  size  of  the  map  display  or  on  a 
specified  map  scale.  Once  the  scale  factor  has  been  determined,  any  number  of 
points  may  be  translated  for  display. 

The  equations  below  assume  a  standard  Cartesian  coordinate  output  is 
required;  that  is,  the  origin  of  the  display  surface  will  be  in  the  center, 
and  X  and  Y  values  may  be  positive  or  negative.  The  SABERS  display  assumes  a 
coordinate  system  with  the  origin  at  the  lower  left,  and  only  positive  values 
of  X  and  Y  are  acceptable.  Therefore,  a  simple  offset  value  is  subtracted 
from  the  equation  results  to  yield  the  proper  SABERS  coordinates. 

Mathematic  symbols  and  their  meanings  are  shown  in  Table  3-1.  Valid 
values  for  latitude  are: 

-90°  <  p  <  90° 

Valid  values  for  longitude  are: 

-18°°  <  y  <  180° 

The  formulae  described  were  taken  from  reference  [93. 

3.7.1  Scale  Factors 

The  following  equations  are  used  to  calculate  the  scale  factors  for  the 
projections  listed. 
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Table  3-1  Mathematic  Symbols 


SYMBOL 

DESCRIPTION 

UNITS 

E 

c 

The  eccentricity  of  the  earth 

— 

er 

Angular  distance  from  point  to  map  center  point 

radians 

i 

An  intermediate  calculation  value 

— 

M 

Map  radius  for  orthographic  projection 

inches 

R 

Radius  of  the  earth 

inches 

S 

Scale  of  map  at  true  scale  latitude 

inches/ inch 

X 

Abcissa  of  translated  point 

inches 

X 

r 

Range  of  X  values  (width  of  map) 

inches 

X  ' 

3 

Scale  factor  in  X  direction 

inches 

Y 

Ordinate  of  translated  point 

inches 

Yr 

Range  of  Y  values  (height  of  map) 

inches 

Y 

3 

Scale  factor  in  Y  direction 

inches 

U 

Longitude  of  point 

rad ians 

> 

Longitude  at  map  center  point 

radians 

ur 

Range  of  longitude  ( absolute  value  of 
eastmost  longitude  -  westmost  longitude) 

radians 

p 

Latitude  of  point 

radians 

% 

Latitude  at  map  center  point 

rad ians 

pc 

Co-latitude  at  point  (p/2  -  p) 

radians 

P  c4> 

Co-latitude  of  center  point  (p/2  -  P^) 

rad ians 

Pr 

Range  of  latitude  (northmost  latitude  -  southmost  latitude) 

rad ians 

Pt 

True  scale  latitude 

rad ians 

4> 

Azimuth  angle  from  point  to  center 

rad ians 
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MEHCAT03,  MILLER.  AMD  SINUSOIDAL 
[1.0  -  Ep  sin2pt]1/2 

1  "  COS 

Xg  =  R/[ iS] 

Ys  =  xs 

EQUIRECTANGULAR 

X  Xr 
•  =  Wr 

Yr 

Ys  =  r  • 

r 

ORTHGRAPHIC 

Xs  5  MYS  =  xs 


3 .7.2  Projection  Equations 

The  following  equations  are  used  to  calculate  the  projections  listed, 
MERCATOR 

X  =  -  V*  ]  •  X, 


i  =  In  tan  [45° 


M,  ** 

♦  -V-]  ♦ 


ln 


1  -  Ec  sin  1p  I 
1  +  Ec  sin  |p  I 


i  assumes  the  sign  of  p  , 
Y  =  i  Y 
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MILLER 


X  =  [P  -  .  xs 

i  =  |  In  [tan  ( -45°  +  2M>] 
i  assumes  the  sign  of  P 

Y  =  i  .  Y 

EQUIRECTANGULAR 

X  =  [»•  -  V  *  Xs 

Y  =  [p-p  ]  •  Ys 


SINUSOIDAL 

X  =  [ p  -  p  ]  •  cos  p • 
$ 

Y  =  P  .  Y 

5 


ORTHOGRAPHIC 


Er  =  cos' 


£cos  Pc^,  cos  Pc  +  sin  pc(j,  sin  p  ccos  |  (p  -  P^)|j 


Ho  to :  This  equation  ir.  the  CAM  documentation  is  marred  by  two  errors. 
This  is  the  correct  equation. 


l  =  co 


«-1 


COS  P  c<(,  -  COS  Er  cos  p 


sin  Er  sir. 


"o’  [u  —  u.j  >4>  ,  $  =  i 

F.  *  (  -  -  p’j  <♦  ,  $  =  180°  -  i 
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1.0  INTRODUCTION 


Fortran  contains  four  basic  mechanisms  for  controlling  program 
flow:  CALL/RETURN,  IF,  DO,  and  various  forma  of  the  GO  TO. 


Flees  is  a  language  extension  of  Fortran  which  has  additional 
control  mechanisms.  These  mechanisms  make  it  easier  to  write 
Fortran  by  eliminating  much  of  the  clerical  detail  associated  with 
constructing  Fortran  programs.  Flees  is  also  easier  to  read  and 
comprehend  than  Fortran. 


This  manual  is  intended  to  be  a  brief  but  complete  introduction  to 
Flees.  It  is  not  intended  to  be  a  primer  on  Flees  or  structured 
programming.  The  reader  is  assumed  to  be  a  knowledgeable  Fortran 
programmer. 


For  programmers  to  whom  transportability  of  their  programs  is  a 
concern,  it  should  be  noted  that  the  Flees  translator  source  code 
is  in  the  public  domain  and  is  made  freely  available.  The 
translator  was  written  with  transportability  in  mind  and  requires 
little  effort  to  move  from  one  machine  to  another.  Those 
interested  in  moving  Flees  to  another  machine  or  in  having  their 
own  copy  of  Flees  should  contact  the  author. 


At  (Jregon,  Flees  is  implemented  on  both  the  PDF- 10  and  the  IbM 
S/360.  The  manner  of  Implementation  is  that  of  a  preprocessor 
which  translates  Flees  programs  into  Fortran  programs.  The 
resulting  Fortran  program  is  then  processed  in  the  usual  way.  The 
translator  also  produces  a  nicely  formatted  listing  of  the  Flees 
program  which  graphically  presents  the  control  structures  used. 


The  following  diagram  illustrates  the  translating  process. 


i 


2.0  RETENTION  OF  FORTRAN  FEATURES 


The  Flees  translator  examines  each  statement  in  the  Flees  program 
to  see  if  it  is  an  extended  statement  (a  statement  valid  in  Flees 
but  not  in  Fortran).  If  it  is  recognized  as  an  extended 
statement,  the  translator  generates  the  corresponding  Fortran 
statements.  If,  however,  the  statement  is  not  recognized  as  an 
extended  statement,  the  translator  assumes  it  must  be  a  Fortran 
statement  and  passes  it  through  unaltered.  Thus  the  Flees  system 
flafig  JQ£&  restrict  U&&  2l  Fortran  statements,  it  simply 
provides  a  set  of  additional  statements  which  may  be  used.  In 
particular,  GO  TOs,  arithmetic  IFs,  CALLs,  arithmetic  statement 
functions,  and  any  other  Fortran  statements,  compiler  dependent  or 
otherwise,  may  be  used  in  a  Flees  program. 


3.0  CORRELATION  OF  FLECS  AND  FORTRAN  SOURCES 


One  difficulty  of  preprocessor  systems  like  Flees  is  that  error 
messages  which  come  from  the  Fortran  compiler  must  be  related  back 
to  the  original  Flees  source  program.  This  difficulty  is  reduced 
by  allowing  the  placement  of  1/lnf  numbers  (not  to  be  confused  with 
Fortran  statement  numbers)  on  Flees  source  statements.  These  line 
numbers  then  appear  on  the  listing  and  in  the  Fortran  source. 
When  an  error  message  is  produced  by  either  the  Flees  translator 
or  the  Fortran  compiler,  it  will  include  the  line  number  of  the 
offending  Flees  source  statement,  making  it  easy  to  locate  on  the 
listing. 


If  the  programmer  chooses  not  to  supply  line  numbers,  the 
translator  will  assign  sequential  numbers  and  place  them  on  the 
listing  and  in  the  Fortran  source.  Thus,  errors  from  the  compiler 
may  still  be  related  to  the  Flees  listing. 


Details  of  line  numbering  are  machine  dependent  and  are  given  in 
chapter  10.  On  most  card  oriented  systems,  the  line  numbers  may 
be  placed  in  columns  76-80  of  each  card.  Other  systems  may  have 
special  provisions  for  line  numbers. 

The  beginning  Flees  programmer  should  discover  and  make 
special  note  of  the  details  of  the  mechanism  by  which  Fortran 
compiler  error  messages  may  be  traced  back  to  the  Flees  listing  on 
the  system  being  used. 
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4.0  STRUCTURED  STATEMENTS 


A  basic  notion  of  Flees  is  that  of  the  structured  statement  which 
consists  of  a  control  Phrase  and  its  scope.  Fortran  has  two 
structured  statements,  the  logical  IF  and  the  DO.  The  following 
examples  illustrate  this  terminology: 


structured  statement 


control  phrase  scope 


keyword  specification 


IF  (X.EQ.Y)  UsV+W 


keyword  specification 


control  phrase 
scope 


structured 

statement 


Note  that  each  structured  statement  consists  of  a  control  phrase 
which  controls  the  execution  of  a  set  of  one  or  more  statements 
called  its  scope.  Also  note  that  each  control  phrase  consists  of 
a  keyword  plus  some  additional  information  called  the 
specification .  A  statement  which  does  not  consist  of  a  control 
phrase  and  a  scope  is  said  to  be  a  simple  statement .  Examples  of 
simple  statements  are  assignment  statements,  subroutine  CALLs, 
arithmetic  IFs,  and  GO  TOs. 


The  problem  with  the  Fortran  logical  IF  statement  is  that  its 
scope  may  contain  only  a  single  simple  statement.  This 
restriction  is  eliminated  in  the  case  of  the  DO,  but  at  the  cost  of 
clerical  detail  (having  to  stop  thinking  about  the  problem  while  a 
statement  number  is  Invented).  Note  also  that  the  IF 
specification  is  enclosed  in  parentheses  while  the  DO 
specification  is  not. 

In  Flees  there  is  a  uniform  convention  for  writing  control  phrases 
and  indicating  their  scopes.  To  write  a  structured  statement,  the 
keyword  is  placed  on  a  line  beginning  in  column  7  followed  by  its 
specification  enclosed  in  parentheses.  The  remainder  of  the  line 
is  left  blank.  The  statements  comprising  the  scope  are  placed  on 
successive  lines.  The  end  of  the  scope  is  indicated  by  a  FIN 
statement.  This  creates  a  multi-line  structured  statement. 
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Examples  of  multi-line  structured  statements: 


L 


(X.EQ.Y) 
U  a  V+W 
R  s  S+T 
FIN 


L 


(I  =  1,N) 

A(I)  a  B ( I ) +C 
C  s  C*2. 14-3. 14 
FIN 


Note:  The  statement  number  has  been  eliminated  from  the  bO 
specification  since  it  is  no  longer  necessary ,  the  end  of  the 
loop  being  specified  "by  the  FIN. 


Nesting  of  structured  statements  is  permitted  to  any  depth. 

Example  of  .nested  structured  statements: 

IF  (X.EQ.Y) 

U  a  V+W 
DO  (I  *  1 , N) 

I  A(I)  a  B ( I ) +C 
C  a  C*2.  14-3.  14 
L-  FIN 
R  a  S+T 
L— FIN 


When  the  scope  of  a  control  phrase  consists  of  e  single  simple 
statement,  it  may  be  placed  on  the  same  line  as  the  control  phrase 
and  the  FIN  may  be  dispensed  with.  This  creates  a  one-line 
atructyrftd  statement. 

Examples  of  one-line  structured  statements: 

IF  (X.EQ.Y)  U  a  V+W 

DO  (I  a  1,N)  A(I)  a  B(I)+C 


1 
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Since  each  control  phrase  must  begin  on  a  new  line,  it  is  not 
possible  to  have  a  one-line  structured  statement  whose  scope 
consists  of.  a  structured  statement. 

Example  of  invalid  construction: 

IF  (X.EQ.Y)  DO  (I  =  1 ,  N )  A(I)  =  B(I)+C 

To  achieve  the  effect  desired  above,  the  IF  must  be  written  in  a 
multi-line  form. 

Example  of  valid  construction: 

IF  (X.EQ.Y) 

I  DO  (I  =  1 ,N)  A( I )  =  B(I)+C 
L_  FIN 


In  addition  to  IF  and  DO,  Flees  provides  several  useful  structured 
statements  not  available  in  Fortran.  After  a  brief  excursion  into 
the  subject  of  indentation,  we  will  present  these  additional 
structures. 


5.0  INDENTATION,  LINES  AND  THE  LISTING 


In  the  examples  of  multi-line  structured  statements  above,  the 
statements  in  the  scope  were  indented  and  an  "L"  shaped  line  was 
drawn  connecting  the  keyword  of  the  control  phrase  to  the  matching 
FIN.  The  resulting  graphic  effect  helps  to  reveal  the  structure 
of  the  program.  The  rules  for  using  indentation  and  FINs  are 
quite  simple  and  uniform.  The  control  phrase  of  a  multi-line 
structured  statement  always  causes  indentation  of  the  statements 
that  follow.  Nothing  else  causes  indentation.  A  level  of 
indentation  (i.e.  a  scope)  is  always  terminated  with  a  FIN. 
Nothing  else  terminates  a  level  of  indentation. 


When  writing  a  Flees  program  on  paper  the  programmer  should  adopt 
the  indentation  and  line  drawing  conventions  shown  below.  When 
preparing  a  Flees  source  program  in  machine  readable  form, 
however,  each  statement  should  begin  in  column  7.  When  the  Flees 
translator  produces  the  listing,  it  will  reintroduce  the  correct 
indentation  and  produce  the  corresponding  lines.  If  the 
programmer  attempts  to  introduce  his  own  indentation  with  the  use 
of  leading  blanks,  the  program  will  be  translated  correctly,  but 
the  resulting  listing  will  be  improperly  indented. 


Example  of  indentation: 


1.  Program  as  written  on  paper  by  programmer. 

IF  (*.5Q.Y ) 

Us  V+W 

Da-  (X 

I  A(i)*B>CL)±c 
C  -  C*2,/¥-3./V 
4 — FIN 

- FIN 

2.  Program  as  entered  into  computer. 

IF  (X.EQ.Y) 

U  3  v+w 
DO  (I  =  1 ,N) 

A(I )  =  B( I )+C 
C  3  0*2.14-3.14 
FIN 

R  s  S+T 
FIN 

3.  Program  as  listed  by  Flees  translator. 

IF  (X.EQ.Y) 

.  U  s  Vt- V 
.  DO  (I  3  1 ,  N ) 

.  .  A( I )  s  B( I )+C 

.  .  C  3  0*2.14-3.14 

.  ...FIN 
.  R  s  S+T 
. . .FIN 

The  correctly  indented  listing  is  a  tremendous  aid  in  reading  and 
working  with  programs.  Except  for  the  dots  and  spaces  used  for 
indentation,  the  lines  are  listed  exactly  as  they  appear  in  the 
source  program.  That  is,  the  internal  spacing  of  columns  7-72  is 
preserved.  There  is  seldom  any  need  to  refer  to  a  straight 
listing  of  the  unindented  source. 

Comment  lines  are  treated  in  the  following  way  on  the  listing  to 
prevent  interruption  of  the  dotted  lines  indicating  scope.  A 
comment  line  which  contains  only  blanks  in  columns  2  through  b 
will  be  listed  with  columns  7  through  72  indented  at  the  then- 
current  level  of  indentation  as  if  the  line  were  an  executable 
statement.  If,  however,  one  or  more  non-blank  characters  appear 
in  columns  2  through  6  of  a  comment  card,  it  will  be  listed  without 
indentation.  Blank  lines  may  be  Inserted  in  the  source  and  will 
be  treated  as  empty  comments. 
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The  complete  set  of  control  structures  provided  by  Flees  is  given 
below  together  with  their  corresponding  flow  charts.  The 
symbol  £  is  used  to  indicate  a  logical  expression.  The 
symbol  S  is  used  to  indicate  a  scope  of  one  or  more  statements. 
Some  statements,  as  indicated  below,  do  not  have  a  one-line 
construction. 

A  convenient  summary  of  the  information  in  this  chapter  may  be 
found  in  Appendix  A. 


6.1  Decision  Structures 


Decision  structures  are  structured  statements  which  control  the 
execution  of  their  scopes  on  the  basis  of  a  logical  expression  or 


6.1.1  IF 


Description:  The  IF  statement  causes  a  logical  expression  to  be 
evaluated.  If  the  value  is  true,  the  scope  is  executed  once  and 
control  passes  to  the  next  statement.  If  the  value  is  false, 
contol  passes  directly  to  the  next  statement  without  execution  of 
the  scope. 


General  Form: 


IF  (£>  S 


Examples : 

IF  (X.EQ.Y)  U  a  V+W 

IF  (T.GT.O.AND.S.LT.R) 
.  I  a  1+1 
.  Z  a  0.  1 
. . .FIN 


Flow  Chart: 


6.1.2  UNLESS 


Description:  "UNLESS  (X)"  is  functionally  equivalent  to 
"IF( .NOT. ( X ) )" »  but  is  more  convenient  in  some  contexts. 


General  Form: 


UNLESS  (  £  )  S 


Examples : 

UNLESS  (X.NE.Y)  U  a  V+W 
UNLESS  (T.LE.0.0R.S.GE.R) 

.  I  a  1+1 

.  Z  a  0. 1 
. . .FIN 


Flow  Chart: 


4-11 


PAR  TECHNOLOGY  CORP  ROME  NY  F/G  9/2 

SABERS.  STAND-ALONE  ADIC  BINARY  EXPLOITATION  RESOURCES  SYSTEM.  — «CTC<U> 
SEP  81  A  J  FRANKLIN.  R  L  CALDWELL.  S  COLE  F30602-78-C-0078 

RADC-TR-81-250-V0L-1  NL 


UNCLASSIFIED 


MICROCOPY  RESOLUTION  TEST  CHART 


6.1.3  WHEN . . . ELSE 


Description:  The  WHEN... ELSE  statements  correspond  to  the 
IF. .  .THEN. . .ELSE  statement  of  Algol,  PL/1,  Pascal,  etc.  In  Flees, 
b^th  the  WHEN  and  the  ELSE  act  as  structured  statements  although 
only  the  WHEN  has  a  specification.  The  ELSE  statement  must 
immediately  follow  the  scope  of  the  WHEN.  The  specifier  of  the 
WHEN  is  evaluated  and  exactly  one  of  the  two  scopes  is  executed. 
The  scope  of  the  WHEN  statement  is  executed  if  the  expression  is 
true  and  the  scope  of  the  ELSE  statement  is  executed  if  the 
expression  is  false.  In  either  case,  control  then  passes  to  the 
next  statement  following  the  ELSE  statement. 


General  Form: 


Flow  Chart: 


WHEN  (£)  $t 
ELSE 


Examples: 


WHEN  (X.EQ.Y)  U 
ELSE  U  =  V-W 

WHEN  (X.EQ.Y) 

.  U  s  V+W 
.  T  s  T+1 .5 
. . .FIN 

ELSE  U  s  V-W 


WHEN  (X.EQ.Y)  U 
ELSE 

.  U  =  V-W 
.  T  =  T+1 .5 
.. .FIN 

WHEN  (X.EQ.Y) 

.  U  =  V+W 
.  T  =  T-1.5 
...FIN 
ELSE 

.  U  s  V-W 
.  T  s  T+1. 5 
. . .FIN 


NOTE:  WHEN  and  ELSE  always  come  as  a  pair  of  statements,  never 
separately.  Either  the  WHEN  or  the  ELSE  or  both  may  assume  the 
multi-line  form.  ELSE  is  considered  to  be  a  control  phrase,  hence 
cannot  be  placed  on  the  same  line  as  the  WHEN.  Thus 
"WHEN  (  £  )  Si  ELSE  &  "  is  valid. 


6.1.4  CONDITIONAL 


Description:  The  CONDITIONAL  statement  is  based  on  the  LISP 
conditional.  A  list  of  logical  expressions  is  evaluated  one  by 
one  until  the  first  expression  to  be  true  is  encountered.  The 
scope  corresponding  to  that  expression  is  executed,  and  control 
then  passes  to  the  first  statement  following  the  CONDITIONAL.  If 
all  expressions  are  false,  no  scope  is  executed.  (See,  however, 
the  note  about  OTHERWISE  below. } 


General  Form: 


Flow  Chart: 


CONDITIONAL 
.  (4>  St 
.  (JCZ)  Sx 


.  (£*>  Sn 

...FIN 

Examples: 

CONDITIONAL 

.  (X.LT.-5.0)  U  s  U+W 

.  (X.LE.1.0)  U  *  U+W+Z 

.  (X.LE.10.5)  U  s  U-Z 

. . .FIN 

CONDITIONAL 
,  (A.EQ.B)  Z  s  1.0 
.  (A.LE.C) 

.  .  Y  s  2.0 

.  .  Z  *  3-4 

.  ...FIN 

.  (A.GT.C.AND.A.LT.B)  Z 
.  (OTHERWISE)  Z  s  0.0 
.. .FIN 
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Notes:  The  CONDITIONAL  itself  does  not  possess  a  one-line  form. 
However,  each  "(4f)  Si  "  is  treated  as  a  structured  statement  and 
may  be  in  one-line  or  multi-line  form. 

The  reserved  word  OTHERWISE  represents  a  catchall  condition.  That 
is,  "(OTHERWISE)  $+  "  is  equivalent  to  "(.TRUE.)  5*  "  in  a 
CONDITIONAL  statement. 


.3 


6.1.5  SELECT 


Description:  The  SELECT  statement  is  similar  to  the  CONDITIONAL 
but  is  more  specialized.  It  allows  an  expression  to  be  tested  for 
equality  to  each  expression  in  a  list  of  expressions.  When  the 
first  matching  expression  is  encountered,  a  corresponding  scope  is 
executed  and  the  SELECT  statement  terminates.  In  the  description 
below, £  ,  On  represent  arbitrary  but  compatible 
expressions.  Any  type  of  expression  (integer,  real,  complex,...) 
is  allowed  as  long  as  the  underlying  Fortran  system  allows '  such 
expressions  to  be  compared  with  an  .EQ.  or  .NE.  operator. 


General  Form: 

SELECT  (£) 

.  (£1)  Si 

.  (£i)  St 


\  (En)  Sn 
...FIN 

Example: 

SELECT  (OPCODE (PC) ) 

.  (JUMP)  PC  =  AD 
.  (ADD) 

.  .  A  =  A+B 

.  .  PC  =  PC+1 

.  ...FIN 

(SKIP)  PC  =  PC+2 
.  (STOP)  CALL  STOPCD 
. . .FIN 


Flow  Chart: 


•  • 


Notes:  As  in  the  case  of  CONDITIONAL,  at  most  one  of  the  St  will 
be  executed. 

The  catchall  OTHERWISE  may  also  be  used  in  a  SELECT  statement. 
Thus  " (OTHERWISE )  Sn  "  is  equivalent  to  "(£)  Sn  "  within  a 
"SELECT  (£)”  statement. 

The  expression  £  is  reevaluated  for  each  comparison  in  the  list, 
thus  lengthy,  time  consuming,  or  irreproducable  expressions  should 
be  precomputed,  assigned  to  a  variable,  and  the  variable  used  in 
the  specification  portion  of  the  SELECT  statement. 


6.2  LOOP  Structures 


The  structured  statements  described  below  all  have  a  scope  which 
is  executed  a  variable  number  of  times  depending  on  specified 
conditions. 

Of  the  five  loops  presented,  the  most  useful  are  the  00,  WHILE,  and 
REPEAT  UNTIL  loops.  To  avoid  confusion,  the  REPEAT  WHILE  and 
UNTIL  loops  should  be  ignored  initially. 


6.2.1  DO 


Description:  The  Flees  DO  loop  is  functionally  identical  to  the 
Fortran  DO  loop.  The  only  differences  are  syntactic.  In  the 
Flees  DO  loop,  the  statement  number  is  omitted  from  the  DO 
statement,  the  incrementation  parameters  are  enclosed  in 
parenthesis,  and  the  scope  is  indicated  by  either  the  one  line  or 
multi-line  convention.  Since  the  semantics  of  the  Fortran  DO 
statement  vary  from  one  Fortran  compiler  to  another,  a  flowchart 
cannot  be  given.  The  symbol  X  represents  any  legal 
incrementation  specification. 


General  Form: 


Equivalent  Fortran: 


DO  (X)  S 


DO  30  X 

s 


30  CONTINUE 


Examples: 

DO  (I  *  1 ,N)  A ( I )  *  0.0 

DO  (J  *  3,K,3) 

.  B(J)  a  B( J- 1 )*B( J-2) 

.  C(J)  *  SIN(B( J) ) 
...FIN 
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6.2.2  WHILE 


Description:  The  WHILE  loop  causes  its  scope  to  be  repeatedly 
executed  while  a  specified  condition  is  true.  The  condition  is 
checked  prior  to  the  first  execution  of  the  scope,  thus  if  the 
condition  is  initially  false  the  scope  will  not  be  executed  at 
all. 


General  Form: 

WHILE  (  £  )  S 


Examples : 

WHILE  (X.LT.A(I))  I 

WHILE  (P.NE.O) 

.  VAL(P)  =  VAL(P)+1 
.  P  =  LINK(P) 

. . .FIN 


6.2.3  REPEAT  WHILE 

Description:  By  using  the  REPEAT  verb,  the  test  can  be  logically 
moved  to  the  end  of  the  loop.  The  REPEAT  WHILE  loop  causes  its 
scope  to  be  repeatedly  executed  while  a  specified  condition 
remains  true.  The  condition  is  not  checked  until  after  the  first 
execution  of  the  scope.  Thus  the  scope  will  always  be  executed  at 
least  once  and  the  condition  indicates  under  what  conditions  the 
scope  is  to  be  repeated ^  Note:  "REPEAT  WHILE(X)"  is  functionally 
equivalent  to  "REPEAT  UNTIL( .NOT. (£) )" . 


General  Form:  Flow  Chart: 

REPEAT  WHILE  (OS 


Examples : 

REPEAT  WHILE(  N.EQ.M(I))  I  *  1+1 

REPEAT  WHILE' (LINK(Q) .NE.O) 

.  R  =  LINK(Q) 

.  LINK(Q)  =  P 
.  P  =  Q 
.  Q  =  R 
. . .FIN 
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6.2.4  UNTIL 


Description:  The  UNTIL  loop  causes  its  scope  to  be  repeatedly 
executed  until  a  specified  condition  becomes  true.  The  condition 
is  checked  prior  to  the  first  execution  of  the  scope,  thus  if  the 
condition  is  initially  true,  the  scope  will  not  be  executed  at 
all.  Note  that  "UNTIL  (£)"  is  functionally  equivalent  to  "WHILE 
(.NOT  .(£))". 


General  Form: 

UNTIL  <  C  )  $ 


Flow  Chart: 


Examples : 

UNTIL  (X.EQ.A(I))  I  a  1+1 

UNTIL  (P.EQ.O) 

.  VAL(P)  •=  VAL(P)  +  1 
.  P  a  LINK(P) 

. . .FIN 


6.2.5.  REPEAT  UNTIL 

Description:  By  using  the  REPEAT  verb,  the  test  can  be  logically 
moved  to  the  end  of  the  loop.  The  REPEAT  UNTIL  loop  causes  its 
scope  to  be  repeatedly  executed  until  a  specified  condition 
becomes  true.  The  condition  is  not  checked  until  after  the  first 
execution  of  the  scope.  Thus  the  scope  will  always  be  executed  at 
least  once  and  the  condition  indicates  under  what  conditions  the 
repetition  of  the  scope  is  to  be  terminated. 

General  Form:  Flow  Chart: 

REPEAT  UNTIL  (OS 


Examples: 

REPEAT  UNTIL  (N.EQ.*<I>)  I  a  1+1 

REPEAT  UNTIL  (LINK(Q) . EQ. 0} 

R  a  LINK(Q) 

LINK(Q)  a  P 


7.0  Internal  Procedures 


In  Flees  a  sequence  of  statements  may  be  declared  an  internal 
procedure  and  given  a  name.  The  procedure  may  then  be  invoked 
from  any  point  in  the  program  by  simply  giving  its  name. 

Procedure  names  may  be  any  string  of  letters,  digits,  and  hyphens 
(i.e.  minus  signs)  beginning  with  a  letter  and  containing  at 
least  one  hyphen.  Internal  blanks  are  not  allowed.  The  only 
restriction  on  the  length  of  a  name  is  that  it  may  not  be  continued 
onto  a  second  line. 

Examples  of  valid  internal  procedure  names: 

INITIALIZE-ARRAYS 

GIVE-WAhNINU 

SOHT-INTO-DESCENDING-ORDER 

INITIATE-PHASE-3 


A  procedure  declaration  consists  of  the  keyword  "TO"  followed  by 
the  procedure  name  and  its  scope.  The  set  of  statements 
comprising  the  procedure  is  called  its  scope.  If  the  scope 
consists  of  a  single  simple  statement  it  may  be  placed  on -the  same 
line  as  the  "TO"  and  procedure  name,  otherwise  the  statements  of 
the  scope  are  placed  on  the  following  lines  and  terminated  with  a 
FIN  statement.  These  rules  are  analogous  with  the  rules  for 
forming  the  scope  of  a  structured  statement. 


General  Form  of  procedure  declaration: 
TO  procedure-name 


Examples  of  procedure  declarations: 

TO  HESET-POINTER  P  =  0 

TO  DO-NOTHING  CONTINUE 

TO  SUMMARIZE-FILE 
.  INITIALIZE-SUMMARY 
.  OPEN-FILE 
.  REPEAT  UNTIL  (EOF) 

.  .  ATTEMPT-TO-READ-RECORD 

.  .  WHEN  (EOF)  CLOSE-FILE 

.  .  ELSE  UPDATE-SUMMARY 

.  ...FIN 
.  OUTPUT-SUMMARY 
. . .FIN 


An  internal  procedure  reference  is  a  procedure  name  appearing 
where  an  executable  statement  would  be  expected.  In  fact  an 
internal  procedure  reference  1a  an  executable  simple  statement  and 
thus  may  be  used  in  the  scope  of  a  structured  statement  as  in  the 
last  example  above.  When  control  reaches  a  procedure  reference 
during  execution  of  a  Flees  program,  a  return  address  is  saved  and 
control  is  transferred  to  the  first  statement  in  the  scope  of  the 
procedure.  When  control  reaches  the  end  of  the  scope,  control  is 
transferred  back  to  the  statement  logically  following  the 
procedure  reference. 

A  typical  Flees  program  or  subprogram  consists  of  a  sequence  of 
Fortran  declarations:  (e.g.  INTEGER,  DIMENSION,  COMMON,  etc.) 
followed  by  a  sequence  of  executable  statements  called  the  body  of 
the  program  followed  by  the  Flees  internal  procedure  declarations, 
if  any,  and  finally  the  END  statement. 

Here  is  a  complete  (but  uninteresting)  Flees  program  which 
illustrates  the  placement  of  the  procedure  declarations. 


00010 

C 

INTERACTIVE  PROGRAM  FOR  PDP-10  TO 

00020 

C 

ZERO  IS  USED  AS  A  SENTINEL  VALUE  T 

00030 

00040 

REAL  X , XSQ 

00050 

REPEAT  UNTIL  (X.EQ.0) 

00060 

• 

GET-A-VALUE-CF-X 

00070 

* 

IF  (X.NE.0) 

00080 

• 

.  COMPUTE-hESULT 

00090 

• 

.  TYPE-RESULT 

00100 

• 

.. .FIN 

00110 

•  •  « 

FIN 

00120 

CALL  EXIT 

00130 

TO 

GET-A-VALUE-OF-X 

00140 

• 

TYPE  10 

00150 

10 

• 

FORMAT  ('  X  =  ',$) 

00160 

• 

ACCEPT  20, X 

00170 

20 

• 

FORMAT  (F) 

00180 

•  • 

FIN 

00190 

TO 

COMPUTE-RESULT  XSQ  s  X*»X 

00200 

TO 

TYPE-RESULT 

00210 

• 

TYPE  30.  XSQ 

00220 

30 

• 

FORMAT (  X-SQUARED  s  ,F7 

00230 

•  •  • 

FIN 

00240 

END 
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Notes  concerning  internal  procedures: 

1 .  All  internal  procedure  declarations  must  be  placed  at  the 
end  of  the  program  just  prior  to  the  END  statement.  The 
appearance  of  the  first  "TO"  statement  terminates  the 
body  of  the  program.  The  translator  expects  to  see 
nothing  but  procedure  declarations  from  that  point  on. 

2.  The  order  of  the  declarations  is  not  important. 

Alphabetical  by  name  is  an  excellent  order  for  programs 
with  a  large  number  of  procedures. 

3.  Procedure  declarations  may  not  be  nested.  In  other 

words,  the  scope  of  a  procedure  may  not  contain  a 

procedure  declaration.  It  may  of  course  contain 

executable  procedure  references. 

4.  Any  procedure  may  contain  references  to  any  other 
procedures  (excluding  itself). 

5.  Dynamic  recursion  of  procedure  referencing  is  not 
permitted . 

6.  All  program  variables  within  a  main  or  subprogram  are 

global  and  are  accessable  to  the  statements  in  all 
procedures  declared  within  that  same  main  or  sub 

program. 

7.  There  is  no  formal  mechanism  for  defining  or  passing 
parameters  to  an  internal  procedure.  When  parameter 
passing  is  needed,  the  Fortran  function  or  subroutine 
subprogram  mechanism  may  be  used  or  the  programmer  may 
invent  his  own  parameter  passing  methods  using  the  global 
nature  of  variables  over  internal  procedures. 

d.  The  Flees  translator  separates  procedure  declarations  on 
the  listing  by  dashed  lines  as  shown  in  the  preceding 
example. 
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ti.O  Restrictions  and  Notes 


If  Flees  were  Implemented  by  a  nice  Intelligent  compiler  this 
section  would  be  much  shorter.  Currently,  however,  Flees  is 
implemented  by  a  sturdy  but  naive  translator.  Thus  the  Flees 
programmer  must  observe  the  following  restrictions. 

1.  Flees  must  invent  many  statement  numbers  in  creating  the 
Fortran  program.  It  does  so  by  beginning  with  a  large  number 
(usually  99999)  and  generating  successively  smaller  numbers  as 
it  needs  them.  Do  not  use  a  number  which  will  be  generated  by 
the  translator.  A  good  rule  of  thumb  is  to  avoid  using  5. 
digit  statement  QUfflfrergu 

2.  The  Flees  translator  must  generate  Integer  variable  names.  It 
does  so  by  using  names  of  the  form  "Innnnn"  when  nnnnn  is  a  5 
digit  number  related  to  a  generated  statement  number.  not 
iia&  variables  &£  £&&  form  Innnrtn  ami  avoid  causing  t.kgffl  £&  &£ 
declared  other  than  INTEGER .  For  example  the  declaration 
"IMPLICIT  REAL  (A-Z)"  leads  to  trouble.  Try  "IMPLICIT  REAL  (A- 
H,  J-Z)"  instead. 

3.  The  translator  does  not  recognize  continuation  lines  in  the 
source  file.  Thus  Fortran  statements  may  be  continued  since 
the  statement  and  its  continuations  will  be  passed  through  the 
translator  without  alteration.  (See  chapter  2.)  However,  an 
extended  Flees  statement  which  requires  translation  aax  &£ 
continued.  The  reasons  one  might  wish  to  continue  a  Flees 
statement  are  1)  It  is  a  structured  statement  or  procedure 
declaration  with  a  one  statement  scope  too  long  to  fit  on  a 
line,  or  2)  it  contains  an  excessively  long  specification 
portion  or  3)  both  of  the  above.  Problem  1)  can  be  avoided  by 
going  to  the  multi-line  form.  Frequently  problem  2)  can  be 
avoided  when  the  specification  is  an  expression  (logical  or 
otherwise)  by  assigning  the  expression  to  a  variable  in  a 
preceding  statement  and  then  using  the  variable  as  the 
specification. 

Blanks  £££  meaningful  separators  XR  LL &££  atatemSDta.;  don't 
nut  them  in  dumb  places  like  the  middle  of  identifiers  or  key 
words  and  da  use  then  to  separate  distinct  words  like  HhPEAT 
and  UNTIL. 

5.  Let  Flees  indent  the  listing.  Start  all  statements  in  col.  2 
and  the  listing  will  always  reveal  the  true  structure  of  the 
program,  (as  understood  by  the  translator,  of  course). 

6.  As  far  as  the  translator  is  concerned,  FORMAT  statements  are 
executable  Fortran  statements  since  it  doesn't  recognize  them 
as  extended  Flees  statements.  Thus,  only  place  FORMAT 
statements  where  an  a&gsmafrls,  fqr.tran  akalsaanl  H SUM 
acceptable.  Don't  put  them  between  the  end  of  a  WHEN 
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statement  and  the  beginning  of  an  ELSE  statement.  Don't  put 
them  between  procedure  declarations. 


Incorrect  Examples: 


Corrected  Examples: 


WHEN  (FLAG)  WRITE(3,30) 
30  FORMAT (7H  TITLE:) 

ELSE  LINE  =  LINE+1 


TO  WRITE-HEADER 
.  PAGE  =  PAGE+1 
.  WRITE( 3 , 40)  H.PAGE 
. . . FIN 

40  FORMAT  (70A1.I3) 


WHEN  (FLAG) 

.  WRITE(3,30) 

30  .  FORMAT (7H  TITLE:) 

•  FIN 

ELSE  LINE  =  LINE+1 

TO  WRITE-HEADER 
.  PAGE  =  PAGE-*- 1 
.  WRITE(3,40)  H , PAGE 

40  .  FORMAT (70A1 ,13) 

. . . FIN 


The  translator,  being  simple-minded,  recognizes  extended  Flees 
statements  by  the  process  of  scanning  the  first  identifier  on 
the  line.  If  the  identifier  is  one  of  the  Flees  keywords  IF, 
WHEN,  UNLESS,  FIN,  etc.,  the  line  is  assumed  to  be  a  Flees 
statement  and  is  treated  as  such.  Thus,  the  Flees  keywords 
are  reserved  and  mav  not  be  used  as  variable  names .  In  case 
of  necessity,  a  variable  name,  say  WHEN,  may  be  slipped  past 
the  translator  by  embedding  a  blank  within  it.  Thus  NWH  EN" 
will  look  like  "WH"  followed  by  "EN"  to  the  translator  which 
is  blank  sensitive,  but  like  "WHEN"  to  the  compiler  which 
ignores  blanks. 


8.  In  scanning  a  parenthesized  specification,  the  translator 
scans  from  left  to  right  to  find  the  parenthesis  which  matches 
the  initial  left  parenthesis  of  the  specification.  The 
translator,  however,  is  ignorant  of  Fortran  syntax  including 
the  concept  of  Hollerith  constants  and  will  treat  Hollerith 
parenthesis  as  syntactic  parenthesis.  Thus,  avoid  placing 
Hollerith  ggnatanla  saalalnlag  unbalanced  parenthsala  within 
specifications .  If  necessary,  assign  such  constants  to  a 
variable,  using  a  DATA  or  assignment  statement,  and  place  the 
variable  in  the  specification. 

Incorrect  Example:  Corrected  Example: 

IF  (J.EQ.  '(  ')  LP  s  '(  ' 

IF(J.EQ.LP) 

9.  The  Flees  translator  will  not  supply  the  statements  necessary 

to  cause  appropriate  termination  of  main  and  sub-programs. 
Thus  a&aaaaacE  ia  include  ids.  appropriate  return,  stop. 

ZL  CALL  £111  Statement  grlfll  la  liia  first  internal  procedure 
declaration.  Failure  to  do  so  will  result  in  control  entering 
the  scope  of  the  first  procedure  after  leaving  the  body  of  the 
program.  Do  not  place  such  statements  between  the  procedure 
declarations  and  the  END  statement. 


9.0  Errors 


This  section  provides  a  framework  for  understanding  the  error 
handling  mechanisms  of  version  22  of  the  Flees  Translator.  The 
system  described  below  is  at  an  early  point  in  evolution,  but  has 
proven  to  be  quite  workable. 

The  Flees  translator  examines  a  Flees  program  on  a  line  by  line 
basis.  As  each  line  is  encountered  it  is  first  subjected  to  a 
limited  syntax  analysis  followed  by  a  context  analysis.  Errors 
may  be  detected  during  either  of  these  analysis.  It  is  also 
possible  for  errors  to  go  undetected  by  the  translator. 


9.1  Syntax  Errors 


When  a  syntax  error  is  detected  by  the  translator,  it  ignores  the 
statement .  On  the  Flees  listing  the  line  number  of  the  statement 
is  overprinted  with  -'s  to  Indicate  that  the  statement  has  been 
ignored.  The  nature  of  the  syntax  error  is  given  in  a  message  on 
the  following  line. 

The  fact  that  a  statement  has  been  ignored  may,  of  course,  cause 
some  context  errors  in  later  statements.  For  example  the  control 
phrase  "WHEN  (X(I) .IT. (3+4)"  has  a  missing  right  parenthesis. 
This  statement  will  be  ignored,  causing  as  a  minimum  the  following 
ELSE  to  be  out  of  context.  The  programmer  should  of  course  be 
aware  of  such  effects.  More  is  said  about  them  in  the  next 
section . 


9.2  Context  Errors 


If  a  statement  successfully  passes  the  syntax  analysis,  it  is 
checked  to  see  if  it  is  in  the  appropriate  context  within  the 
program.  For  example  an  ELSE  must  appear  following  a  WHEN  and 
nowhere  else.  If  an  ELSE  does  not  appear  at  the  appropriate  point 
or  if  it  appears  at  some  other  point,  then  a  context  error  has 
occurred.  A  frequent  source  of  context  errors  in  the  initial 
stages  of  development  of  a  program  comes  from  miscounting  the 
number  of  FIN's  needed  at  some  point  in  the  program. 


With  the  exception  of  excess  FIN's  which  do  not  match  any 
preceding  control  phrase  and  are  ignored  (as  indicated  by 
overprinting  the  line  number),  all  context  errors  are  treated  with 
a  uniform  strategy.  When  an  out-of-context  source  statement  is 
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encountered,  the  translator  generates  a  "STATEMENT (S)  NEEDED" 
message.  It  then  invents  and  processes  a  sequence  of  statements 
which,  if  they  had  been  included  at  that  point  in  the  program, 
would  have  placed  the  original  source  statement  in  a  correct 
context.  A  message  is  given  for  each  such  statement  invented. 
The  original  source  statement  is  then  processed  in  the  newly 
created  context. 

By  inventing  statements  the  translator  is  not  trying  to  patch  up 
the  program  so  that  it  will  run  correctly,  it  is  simply  trying  to 
adjust  the  local  context  so  that  the  original  source  statement  and 
the  statements  which  follow  will  be  acceptable  on  a  context  basis. 
As  in  the  case  of  context  errors  generated  by  ignoring  a 
syntactically  incorrect  statement,  such  an  adjustment  of  context 
frequently  causes  further  context  errors  later  on.  This  is  called 
propagation  &£  errors. 

One  nice  feature  of  the  context  adjustment  strategy  is  that 
context  errors  cannot  propagate  past  a  recognizable  procedure 
declaration.  This  is  because  the  "TO"  declaration  is  in  context 
only  at  indentation  level  0.  Thus  to  place  it  in  context,  the 
translator  must  invent  enough  statements  to  terminate  all  open 
control  structures  which  proceed  the  "TO".  The  programmer  who 
modularizes  his  program  into  a  collection  of  relatively  short 
internal  procedures,  limits  the  potential  for  propagation  of 
context  errors. 


9.3  Undetected  Errors 


The  flees  translator  is  ignorant  of  most  details  of  Fortran 
syntax.  Thus  most  Fortran  syntax  errors  will  be  detected  by  the 
Fortran  compiler  not  the  Flees  translator.  In  addition  there  are 
two  major  classes  of  Flees  errors  which  will  be  caught  by  the 
compiler  not  the  translator. 

The  first  class  of  undetected  errors  involve  misspelled  Flees 
keywords.  A  misspelled  keyword  will  not  be  recognized  by  the 
translator.  The  line  on  which  it  occurs  will  be  assumed  to  be  a 
Fortran  statement  and  will  be  passed  unaltered  to  the  compiler 
which  will  no  doubt  object  to  it.  For  example  a  common  error  is  to 
spell  UNTIL  with  two  L's.  Such  statements  are  passed  to  the 
compiler,  which  then  produces  an  error  message.  The  fact  that  an 
intended  control  phrase  was  not  recognized  frequently  causes  a 
later  context  error  since  a  level  of  indentation  will  not  be 
triggered. 

The  second  class  of  undetected  errors  Involves  unbalanced 
parentheses.  (See  also  note  8  in  section  8.0).  When  scanning  a 
parenthesized  specification,  the  translator  is  looking  for  a 
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matching  right  parenthesis.  If  the  matching  parenthesis  is 
encountered  before  the  end  of  the  line  the  remainder  of  the  line  is 
scanned.  If  the  remainder  is  blank  or  consists  of  a  recognizable 
internal  procedure  reference,  all  is  well.  If  neither  of  the 
above  two  cases  hold,  the  remainder  of  the  line  is  assumed 
(without  checking)  to  be  a  simple  Fortran  statement  which  is 
passed  to  the  Compiler.  Of  course,  this  assumption  may  be  wrong, 
thus  the  statement 

"V/HEN  (X.LT. A(I)+Z) )  X  =  0" 

is  broken  into 

keyword  "WHEW" 

specification  "(X.LT.A(I)+Z)" 

Fortran  statement  ")  X  =  0” 

Needless  to  say  the  compiler  will  object  to  " )  X  =  0"  as  a 
statement . 


Programmers  on  batch  orientea  systems  have  leas  difficulty  with 
undetected  errors  due  to  the  practice  of  running  the  program 
through  both  the  translator  and  the  compiler  each  time  a  run  is 
submitted.  The  compiler  errors  usually  point  out  any  errors 
undetected  by  the  translator. 

Programmers  on  timesharing  systems  tend  to  have  a  bit  more 
difficulty  since  an  undetectea  error  in  one  line  may  trigger  a 
context  error  in  a  much  later  line.  Noticing  the  context  error, 
the  programmer  does  not  proceed  with  compilation  and  hence  is  not 
warned  by  the  compiler  of.  the  genuine  cause  of  the  error.  Une 
indication  of  the  true  source  of  the  error  may  be  an  indentation 
failure  at  the  corresponding  point  in  the  listing. 


9.4  Other  Errors 


The  translator  detects  a  variety  of  other  errors  such  as  multiply 
defined,  or  undefined  procedure  references.  The  error  messages 
are  self-explanatory.  (Really  and  truly!) 
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10.0  Procedure  for  use 


The  following  subsections  describe  the  procedures  for  using  the 
Flees  translator  on  various  machines  at  the  University  of  Oregon. 


10.1  On  the  PDP-10 


10.1.1  Source  Preparation 


Prepare  a  Flees  source  file  with  any  name  of  your  choosing  and  an 
extension  of  ".FLX".  The  translator  will  accept  either 
line-numbered  (SOS,  LIMED,  EDITS)  or  non-line-numbered  (TECO) 
files.  The  advantage  of  line  numbered  files  is  that  the 
translator  and  compiler  error  messages  may  be  related  directly  to 
the  source  file  without  reference  to  a  listing.  As  with  Fortran 
the  "tab  to  column  7”  convention  may  be  used. 


10.1.2  Compile  Commands 


The  Compile  class  commands  (COMPILE,  EXECUTE,  LOAD,  etc.) 
recognize  the  extension  .FLX  and  will  invoke  the  Flees  translator 
when  necessary.  When  invoked,  the  Flees  translator  will  send  any 
error  messages  to  the  TTY  and  will  normally  produce  an  .  F4  file. 
The  /NOBIN  switch  will  suppress  production  of  the  .F4  file  and 
should  only  be  used  with  the  "COMPILE"  command.  The  /LIST  switch 
will  cause  the  translator  to  produce  an  indented  and  formatted 
source  listing  with  extension  .LST  which  may  then  be  TYPE  or 
PRINT  'ed . 

Examples:  (Assume  file3  A. FLX,  B.F4,  C.MAC). 

.EX  A,  B,  C  Produce  A.F4  using  Flees,  then  compile  A.F4 

and  B.F4,  then  assemble  C.MAC,  then  load  and 
execute  A.REL,  B.REL,  and  C.REL. 

.COM/NOBIN/LIST  A  Produce  an  indented  listing  of  A. FLX  but 

don't  produce  A.F4. 

.COM  A  Run  A. FLX  through  Flees,  then  A.F4  through 

Fortran. 

Note  1:  Uninvoked  internal  procedures  and  too  many  or  too  few 
"FIN"'s  preceeding  a  TO  or  END  statement  are  considered  minor 
errors  by  Flees.  All  others  are  considered  major.  If  any 
major  errors  are  detected  by  the  translator,  it  will  abort  any 
following  compilation,  loading,  and  execution. 


Note  2:  (COMPIL  invokes  the  Flees  translator  whenever  the  ".F4" 
file  is  missing  or  older  than  the  ".FLX"  file,  regardless  of 
the  existance  or  time  of  a  ".REL"  file.  If  you  wish  to  save 
disk  space  by  deleting  the  .F4  file,  you  must  then  use  .EX 
A.REL  or  .EX/REL  A  to  avoid  retranslation  and  recompilation . 

Note  3:  If  COMPIL  finds  an  .F4  file  which  is  newer  than  the  .FLX 
file  it  assumes  (without  looking)  that  the  .REL  file  also 
exists.  LINK  will  be  unhappy  if  this  is  not  true.  To  create 
a  new  .REL  file  without  retranslation,  do  .EX  A.F4. 


10.1.3  Explicit  Invocation 


Flees  may  be  invoked  explicitely  by  B.R  FLECS" .  Flees  will 
prompt  with  a  "•"  to  which  you  may  respond  with  any  of  the 
command  formats  below: 

COMMAND  ACTION  • 


<CH>  TERMINATE  EXECUTION 
C  F4  LST  ERR 

*C  ERR 

,  aC  ERR 

A  aC  F4  ERR 

A,  aC  F 4  ERR 

,BaC  LST  ERR 

A , BaC  F 4  LST  ERR 

where  blanks  may  be  used  freely  and 
<CR>  represents  a  carriage  return 
A,B, C  represent  file  specifications  (see  below). 

F4  means  an  ",F4"  file  will  be  produced 
LST  means  an  ".LST"  file  will  be  produced. 

ERR  means  error  messages  will  be  sent  to  the  TTY. 

File  Specification  Format 


DEV:FNAME. EXT[PPN ] 


SYMBOL 

MEANING 

DEV: 

device 

FNAME 

file  name 

.EXT 

extension 

[PPN] 

pro j, prog  # 

Note : 

the  Flees  tr 

DEFAULT  IF  OMITTED 
DSK: 

must  be  specified  in  all  cases  except 
command  format  "C"  where  the  name  given 
to  the  n.FLXn  file  is  also  used  for  the 
".F4",  and  ".LST"  files. 

".F4"  for  A  above 
".LST"  for  B  above 
".FLX"  for  C  above 
same  as  job  using  Flees. 


each  output  file  omitted 
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10.2  On  the  IBM  S/36O 


On  the  IBM  S/3bO  there  are  two  ways  of  accessing  Flees  which  have 
come  to  be  known  as  WATFLECS  and  Standard  Flees.  WATFLECS  is  a 
specially  adapted  version  of  the  Flees  translator  which  processes 
batches  of  short  jobs  using  the  WATFIV  compiler  and  is  used 
primarily  in  connection  with  Computer  Science  classes.  Standard 
Flees  is  a  stand  alone  Flees  translator  used  for  larger  production 
programs,  usually  in  conjunction  with  the  level  U  Fortran 
compiler.  Catalogued  procedures  which  are  analogous  to  those  for 
Fortran(G)  exist  for  using  Standard  Flees.  WATFLECS  is  accessed 
through  a  special  submission  process.  The  same  Flees  translation 
logic  is  used  for  both  systems  so  the  only  language  differences 
are  those  due  to  the  incompatibilities  of  the  corresponding 
Fortrans . 


10.2.1  WATFLECS 


The  procedure  for  preparing  and  submitting  a  program  under 
WATFLECS  is  almost  identical  to  the  procedure  for  submitting  a  job 
under  WATFIV.  The  deck  set  up  is  shown  below 

$ JOB  10Q557/yourname,any-desired-watfiv-parameters,KPs29 


Flees  source  program 


$Ehlh¥ 


data  cards  (if  any) 


Steps  in  submitting  a  WATFLECS  job: 

1.  Prepare  the  Flees  program  or  programs  and  data  cards  on  an  029 
keypunch.  Although  WATFIV  will,  the  WATFLECS  translator  will 
not  accept  cards  punched  on  an  026  keypunch. 

2.  Prepare  a  solid  pink  $J0E  card  as  shown  above. 

a)  The  characters  w$JQb"  should  begin  in  column  1. 

b)  The  account  number  100557  should  begin  in  column  7, 
followed  by  a  "/". 

c)  Fill  in  your  name  followed  by  a  comma. 

6)  Supply  any  desired  WATFIV  parameters.  Note:  the  WATFIV 
part  of  the  run  will  be  limited  to  6  seconds, 
e)  Supply  the  required  nKP*29"  parameter. 


mfl* 


4-28 


3*  Flace  the  Flees  program  behind  the  $JOb  card. 

4.  Place  a  card  with  "SENTRY"  beginning  in  column  1  behind  the 

program.  ££JiM  card  Bttfit  &lKfi£B.  fifi  Present  whether  qz 

not  there  are  anv  data  cards. 

5.  Place  any  data  cards  behind  the  GENTRY  card. 

6.  Place  a  rubber  band  around  the  deck  and  submit  to  program 
reception.  The  receptionist  will  place  a  numbered  comment 
card  in  the  program  and  give  a  duplicate  card  as  a  receipt. 

7.  Check  the  latest  WATFLECS  job  number  posted  on  the  blackboard 
at  program  reception.  As  soon  as  the  posted  number  is  greater 
than  or  equal  to  the  receipt  number,  pick  up  the  deck  and 
listings  by  presenting  the  receipt  card. 


Notes  on  preparing  a  WATFLECS  program: 

1 .  M  Q21  teXBttflfih  must  &&  used. . 

2.  WATFIV  does  not  follow  the  ANSI  standard  for  Fortran  in  that 

it  does  not  allow  a  Fortran  program  to  jump  out  of  the  scope  of 
a  DO  and  later  jump  back  in.  Since  Flees  internal  procedure 
calls  are  implemented  by  GO  TO's,  ia.  not  possible  to 

reference  Internal  BCfififi&MCS  within  ills.  gfifipfi  fi£  a  lfifitt. 
when  using  WATFLECS.  The  other  loop  structures  may  be  used  to 
simulate  a  DO  loop,  however. 

3.  Terminate  a  MTfUCS  main  prggraa  fix.  Biasing  a  gia.tsasat 
ahead  &£  i&s.  first  internal  pr.as  sauce  teslaratiga, 

4.  The  following  unit  numbers  are  available  in  WATFLECS. 

unit  gacaaa.fi 

1  card  input  (from  $EWThY  cards) 

2  undefined 

3  printed  output 

4-7  scratch  disk  (read/write) 

d-10  class  input  data  sets  (read  only) 

5.  The  various  cards  which  control  the  listing  of  a  WATFIV 

program  may  be  included  in  the  program  but  will  be  ignored  by 
the  current  WATFLECS  system. 

6.  The  user  may  wish  to  employ  the  NOWARN  and  NOEXTEh  WATFIV - 
parameters  since  Flees  generated  Fortran  triggers  a  lot  of 
warnings  and  extensions. 
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10. 2. H  standard  Klees 


A  cataloged  JCL  procedure  exists  for  using  the  Klees  translator  as 
a  stand  alone  program.  In  addition  cataloged  procedures  exist  for 
running  Klees  followed  by  Fortran  (G>. 


Data  seta  £££  iiis.  ICaoaiAfefliLL 

The  translator  requires  three  -data  sets  with  the  following  DD 
names . 

LIST  is  the  output  data  set  containing  the  Flees  listing. 

FOhl'OUT  is  the  output  data  set  containing  the  Fortran  source 
produced  by  the  translator. 

SYSIN  is  the  input  data  set  containing  the  Flees  source. 

The  DCb  information  for  these  data  sets  is  given  below.  It  is 
fixed  by  and  contained  in  the  program  hence  need  not  be  specified 
in  the  JCL. 

LIST  DCb=  ( KECFMsKA ,  bLKSIZE*  1 3  :> ) 

FOKTUUT  UCbs ( KECFhs K , bLKSIZEs&G ) 

SYSIN  UCb=(HhCFMcF,bLA'SIZEsbO) 


Using  ilii  translator  a  stand  alone-  J£fl££a ffli 

The  cataloged  procedure  FLECS  is  a  one  step  procedure  which  runs 
the  Flees  translator.  The  user  must  supply  the  SYSIN  data  set. 
Default  DD  statements  in  the  procedure  send  LIST  to  the  printer 
and  FOftTOUT  to  a  dummy  data  set.  If  desired,  these  DD  statements 
may  be  overridden  as  illustrated  in  the  examples  below. 


Example:  Obtaining  a  printed  F lec3  listing  and  ignoring  the 
Fortran  source  proauced. 


//  jobname  JOB 

//  stepname  EXEC 

//  SYSIN  DD 


accounting  information 
FLECS 

« 


Klees  source  program 
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Example:  obtaining  a  printed  version  of  both  the  Flees  listing  and 
the  Fortran  source. 


// 

jobname 

JOB 

accounting  information 

// 

stepname 

EXEC 

FLECS 

// 

FORTOUT 

Ob 

SYSOUTsA 

// 

SYSIN 

DD  . 

* 

Flees  source  program 

/* 


Example:  Obtaining  a  printed  version  of  the  Flees  listing  and 
passing  the  Fortran  source  to  the  Fortran (H)  compiler  for 
compilation'  only.  (This  example  illustrates  the  general  method  of 
passing  the  Fortran  source  on  to  a  subsequent  step  and  suppressing 
the  Fortran  listing.) 


// 

jobname 

JOB 

accounting  information 

// 

stepname 1 

EXEC 

FLECS 

// 

FORTOUT 

DD 

DSNAMEsATEMP , DISP= ( NEW , PASS ) , 

// 

UNITsSYSDA , SPACEs (Cl L , (1,1)) 

// 

SYSIN 

DD 

* 

Flees 

source 

// 

stepname2 

EXEC 

FOttTHC , P ARM . FOKT= 'NOSOUHCE ' 

// 

FORT. SYSIN 

DD 

DSNAMEsATEMP , DISP* ( OLD , DELETE ) 

Using  ihs. 


with  Fortran  (0) : 


Several  cataloged  procedures  have  been  established  which  simplify 
the  process  of  using  Flees  together  with  Fortran  (G).  The 
procedure  names  are  given  below  together  with  the  Fortran 
procedures  to  which  they  correspond. 


FLECSC  FOKTGC 

FLECSCL  FORTGCL 

FLECSCLG  FOHTGCLG 

t'LECSGO  FORTGO 


The  reader  is  assumed  to  be  familiar  with  the  "FOKTU"  procedures. 
The  Flees  procedures  have  been  derived  from  the  FORTG  procedures 
by  adding  an  initial  step  named  FLECS  which  runs  the  Flees 
translator  and  which  passes  the  FORTOUT  data  set  to  the  following 
step.  Since  error  messages  from  the  Fortran  compiler  will  contain 
the  line  number  of  the  original  Flees  source  statement,  the 
programmer  will  have  little  occasion  to  use  the  source  listing 
produced  by  the  Fortran  compiler.  For  this  reason  the  source 
listing  from  the  Fortran  compiler  has  been  suppressed  by  including 


a  'uosuuhCfc'  parameter  l‘or  the  Fortran  compiler. 

Example:  Translating,  compiling,  linkage  editing  and  executing  a 
Flees  program  with  previously  compiled  object  decks  and  data. 

//  jobname  JOB  accounting  information 

//  stepname  EXEC  FLECSCLG 

//  FLECS.SYSIN  DD  • 

Flees  source  program 

/* 

//  LKED.SYS1N  DD  * 

Previously  compiled  or  assembled  object  decks 

/* 

//  GO.SYSIN  LiU  * 

input  data 


/* 

Note:  To  obtain  Nhe  source  listing  from  the  Fortran  compiler, 
replace  the  "EXEC*  '.ard  above  with  the  following: 

//  stepname  EXEC  FLECSCLG , FARM . FORT*  'SOURCE  ' 


In  general,  a  Flees  run  using  one  of  the  Flees  procedures  is 
identical  to  a  Fortran (0)  run  using  the  corresponding  FORTG 
procedures  with  the  following  changes: 

1.  Change  the  procedure  name  from  FORTGxxx  to  FLECSxxx 
(exception  FOKTGO  becomes  FLECSGO) 

2.  Change  the  SYSIN  DD  card  from  FORT.SYSIN  to  FLECS.SYSIN. 

3.  If  desired,  override  the  suppression  of  the  source 
listing  by  including  PARM.FGkT*  SOURCE'  on  the  EXEC  card 
as  described  above. 
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mote:  PUCE  a  PETURN.  STOP,  or 
CALL  EXIT  STATEMENT  AHEAD 
Of  THE  FIRST  TO  STATEMENT. 


NOTE: 


LEGEND 


OTHERWISE  can  be  used  as 

A  CATCHALL  CONDITION  OR 
EXPRESSION  IN  CONOITIOHAL 
AND  SELECT  STATEMENTS. 

C  -  LOGICAL  EXPRESSION 
S  m  STATEMENT^) 

C  •  EXPRESSION 
T  -  DO  SPECIFICATION 


This  duplicate  Plecs  Summary  Sheet  may  be  removed  from  the  manual. 


NOTE:  PLACE  A  #ETIJRN.  STOP.  OR 
CALL  EXIT  STATEMENT  AHEAD 
OF  THE  FIRST  TO  STATEMENT. 


NOTE:  OTHERWISE  can  be  used  as 

A  CATCHALL  CONDITION  OR 

expression  in  CONDITIONAL 
AND  SELECT  STATEMENTS. 

LEGEND:  4  •  LOGICAL  EXPRESSION 

S  *  statement(s) 

£  *  EXPRESSION 
X  •  DO  SPECIFICATION 


APrblJblX  b:  Available  bocumentation  Concerning  Flees 
(As  of  becember  1 97^ - ) 


beyer,  1.,  Flees  Users  Manual  (University  of  Oregon  bdition) 

Contains  a  concise  description  of  the  Flees  extension  of 
Fortran  and  of  the  details  necessary  to  running  a  Flees 
program  on  the  PDP-1U  or  the  IBM  S/360  at  Oregon. 


Beyer,  T. ,  Flees:  System  Modification  Guide 

Contains  information  of  interest  to  anyone  who  wishes  to 
install  or  adapt  the  Flees  system  to  a  new  machine  or 
operating  system.  Also  of  Interest  to  those  who  wish  to 
improve  the  efficiency  of  the  system  by  rewriting  portions  of 
the  system  in  assembly  language. 


